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PREFACE 

• ■ %• 

This report documents the results of a study conducted by the McDonnell 
Douglas Astronautics Company (MDAC) from 1 Tune 1976 to 31 March 1977 
for the NASA George C. Marshall Space Flight Center (MSFC) related to 
integrated payload and mission planning for Space Transportation System 
(STS) payloads. This Phase III effort is a continuation of the Shuttle payload 
planning studies initiated by NAS A/MSFC in October 1974. 

An executive summary of this phase is reported inMDC-6740. Final 
detailed technical results of this study phase are reported in the following 
volumes of MDC G6741: 

Volume I - Integrated Payload and Mission Planning Process 
Evaluation 

Volume II - Logic /Methodology for Preliminary Grouping of 
Spacelab and Mixed Cargo Payloads 

Volume III - Ground Data Management Analysis and Onboard 
Versus Ground Real-Time Mission Operations 

Volume IV - Optimum Utilization of Spacelab Racks and 
Pallets 


This Volume III presents the results of two principal study tasks related to 
data management and mission control. Part I contains the results of a study 
td analyze Spacelab payload real-time onboard versus ground mission 
operations support. A cost relationship of three assumed cases Of onboard 
versus ground capab ility was developed. Part II contains the results of a 
study to analyze the Spacelab experiment-operations ground -data manage- 
ment problem and to establish an effective approach for ground data proc- 
essing to support real-time operations as well as postflight analysis. 
Information in the Appendixes includes a brief review of lessons learned 
from major programs involving payload integration and a checklist that 
would help to minimize integration-related problems. 
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PART I 

ONBOARD VERSUS GROUND REAL-TIME MISSION OPERATIONS 

(TASK 2. 2C) 


PART I - SUMMARY 

The payloads tentatively planned to fly on the first two Spacelab missions 
were analyzed to examine the cost relationships of providing mission opera- 
tions support from onboard vs the ground-based Payload Operations Control 
Center (FOCC). 


Cost relationships were determined for three assumed cases of onboard vs 
ground capability. The three cases were defined as follows: 

9 Case 1 — A full data- and- command centralized POCC with minimum 
onboard control, display, and data processing. 

* Case 2 — A voice-only centralized POCC with maximum onboard 

control, display, and data processing. 

• Case 3 — Data and command systems added to a voice-only cen- 

tralized POCC to permit mission feasibility or significantly 
reduce overall costs. Complementary onboard equipment 
will be used as required. 

Initially, Case 3 was to be limited to ground display of minimum payload- 
system data. However, early in the study it was discovered that display of 
scientific data Was cost effective for many payloads and the Case 3 POCC 
configuration was revised accordingly. 


The study was conducted by performing an individual analysis of each experi- 
ment to define its operating modes and support requirements for each of the 
three cases. These individual experiment operating plans were then inte- 
grated and revised as necessary to assure overall mission compatibility. 

The onboard and ground support requirements, including hardware, software, 
and support personnel were then identified and costed. Cost figures were 
established as differences to a Case 1 baseline except for POCC operations 
which were identified as total support requirements. By ground rule, cost 
savings were not derived for POCC and onboard hardware not utilized to 
support the various cases. Cost results are summarized in Figure 1-1. 
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’OPERATIONS HOURS CONVERTED TO DOLLARS USING 830/HR 


Figure 1-1. Onboard vs Ground Operations Cost Summary 


The quantitative results of this study indicate that use of a POCC, with data 
processing capability, to support real-time mission operations would be the 
most cost effective case. Specifically, the added cost in crew training and 
onboard software or hardware needed to make Case 2 feasible more than 
offset the additional POCC operations costs for Cases 1 or 3, Case 2 costs 
approximately $500, 000 more for Spacelab 1 and $200, 000 more for Space - 
lab 2. / • -y ■ ■■ | , 

In addition, several qualitative factors should be considered in comparing 
the three cases. These factors are; 

A. Scientific Return 

E . Operational Flexibility' 

C. Onboard Equipment Resources 

D. Flight Crew Utilization 
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SCENTIFIC RETURN 

It is not possible to get the same experiment scientific return in Case 2 as 
it is in Case 1 or Case 3. The very nature of scientific experimentation 
requires frequent evaluation of experiment o'-^puts with readjustments of 
inputs to obtain the desired results, Evaluation of outputs often requires 
years of education, training, and experience available only through the 
dedicated scientist. Experimentation time availability coupled with the 
inherent problems of verbal communication required in Case 2 preclude the 
ground-based scientist of providing the most effective interface with his 
experiment. 

The required scientific knowledge can partially be translated to onboard 
operations by increasing crew size (allowing more time per experiment), 
providing extensive crew training, and providing complex automated 
scientific data processing and evaluation programs. These approaches 
increase the cost yet still fail to give the same degree of scientific return 
as available through the well-informed ground-based scientist of Case 1 
and Case 3. 

OPERATIONAL FLEXIBILITY 

The ability to monitor and control payloads from the ground (Cases 1 and 3) 
provides a significant degree of flexibility not available in Case 2. Should 
onboard problems (e. g, , crew sickness or diversion of attention from one 
payload to problem investigation of another payload or STS support system) 
preclude accomplishment of scheduled payload activities, ground control 
could be assumed with a potential of salvaging significant payload operations, 

The requirements for increased crew training and the increased complexity 
of onboard hardware and/or software required by Case 2 would minimize the 
flexibility for changing payloads late in the prelaunch preparation phases. 
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ONBOARD EQUIPMENT RESOURCES 

The increased, demand for added hardware, software, and crew to support 
Case 2 may significantly deplete STS-provided resources for payload support. 
Case 2 would tend to increase weight, power consumption, data processing 
resources, and habitation support resources. The result of these demands 
may necessitate a decrease in payload-carrying capability. The introduction 
of the more sophisticated payloads beyond those studied for Spacelabs 1 and 2 
would accentuate this problem. 

PLIGHT CREW UTILIZATION 

There are certain payloads where an increase in crew utilisation can result 
in a reduction of ground support requirements and still produce the same 
scientific return. Recognizing these situations and planning accordingly 
should result in an overall reduction of real-time dperational costs. This 
increased crew utilization is reflected in Case 3 of this study. The crew 
activity required to support Case 2 was determined to be an extremely heavy 
workload, particularly for the Spacelab 1 type payloads. 

In conclusion, it appears that a Case 3 configuration, which includes real- 
time ground-based scientific data-proces sing capabilities, would result in 
the most cost-effective approach to real-time payload mission operations 
support. 



Section 1 
INTRODUCTION 

The Space Transportation System (STS) currently under development by 
NASA will begin a new era of space activity that will involve a significant 
increase in the number and type of space payloads and missions. To satisfy 
the needs of the various payload users and in order to utilize the STS in the 
most effective way, additional emphasis is being given by NASA to the unique 
planning and program integration activities necessary to fully exploit STS 
capabilities. This planning and integration process becomes extremely 
important when considering the high rate of projected STS traffic, the 
frequent requirement for payload sharing of STS flights, the varied states 
of payload development, and the different operational aspects of each payload. 
These activities include studies of cost-effective approaches to payload 
integration and mission operations, Real-time mission support of the 
Spacelab payload operations is a significant component of the overall payload 
integration cost. 

This report documents the results of an analytical study performed to examine 
the cost relationships of providing payload real-time mission operation sup- 
port from onboard vs the ground-based Payload Operations Control Center 
(POCC). 

1.1 PURPOSE 

The purpose of this task was to perform a trade study which examined the 
cost relationship of three assumed cases of onboard vs ground capability. 

The three cases are (1) full data- and- command centralized POCC with mini- 
mum onboard control, display, and data processing; (2) voice-only centralized 
POCC with maximum (within STS accommodations capability) onboard control, 
display, and data processing; and (3) data and command systems added to a 
voice-only centralized POCC to permit mission feasibility or significantly 
reduce overall costs. Complementary onboard equipment will be used as 
required. 



1. 2 JCOPE 

This task was conducted during the period from November 1976 through 
31 March 1977. The study was limited to an evaluation of the experiments 
from the Spacelab Missions 1 and 2 as defined by the MSFC Strawman 
Summary documents. Refer to Figure I- 1-1 for a listing of experiments. 
During the conduct of the study, such realities as the Tracking and Data Relay 
Satellite System (TDRSS) blackout periods, data downlink constraints, and the 
value of man- on-the- scene were considered for the minimum onboard opera- 
tions of Case 1. Man-in-the-loop vs automation comparisons were empha- 
sized for the onboard operations of Cases 2 and 3. 
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SPACELAB-1 5PACELAB-2 

(7 DAYS - 196 EXP HRS) (12 DAYS - 1091 EXP HRS) 

NASA PAYLOAD 5 NASA PAYLOADS 

1. 65-CM PH0T0HEU0GRAP.H { I PS) 

2. SOLAR MONITOR PACKAGE (IPS) 

3. SOFT X-RAY TELESCOPE (IPS) 

4 LYMAN-ALPHA WHITE-LIGHT 

CORONOGRAPH (IPS) 

5. H1GH-SENSITIVITYX-RAY BURST 
DETECTOR (IPS) 

6. SKYLARK COSMIC X-RAY 
TELESCOPE (MPM) 

7. LOW LIGHT LEVEL TV (MPM) 

8. FAR UV SCHMIDT CAMERA/ 
SPECTROGRAPH (MPM) 

9. TRANSITION RADIATION . 
SPECTROMETER 

10. EUV IMAGING TELESCOPE 
- VFI (VERIFICATION FLIGHT 
INSTRUMENTATION) 


Figure [-1-1. Specelab Experiments (Strawman) 


1. Spacelab 1 Strawman, MSFC, SE-0 12-020-2H, October 1976j and 
Spacelab 2 Strawman, MSFC, SE-0 12-022-28, December 1976. 



1. AP-09-S ELECTRON ACCELERATOR 

2. AP-13-S LOW LIGHT LEVEL TV 

3. ST-31- S DROP DYNAMICS 

4 EQ-01-S ZERO-G CLOUD PHYSICS 

5. LS-13-S MINILAB 

- VFI VERIFICATION FLT INStR 

ESA PAYLOADS 

1. APE-01 LIDAR 

2. S PE-80-85 SPACE PROCESSING 

3. S PE-01 FREE-FLOW ELECTROPHORESIS 

4 EOE-Ol METRIC CAMERA 

5. APE-07 INFRARED RADIOMETER 

6. STE-10 HEAT PIPE 

7. ASE-01 WIDE-FIELD GALACTIC CAMERA 

IPS - ESA INSTRUMENT POINTING SUBSYSTEM 
MPM -MINIATURIZED POINTING MOUNT 


1. 3 GROUND RULES AND ASSUMPTIONS 

A. Case I (maximum FOCG /minimum onboard) 

* Experiment will be monitored and controlled at the FOCC; 
onboard control will be minimized. 

® Must consider TDRSS blackout periods, data downlink con- 
straints, and value of man-on- the -scene. 

B. Case 2 (voice-only PO C C / maximum onboard) 

* All experiment operational data transmission and commands 
shall be voic^-only to and from a centralized FOCC. 

« Man- in- the -loop vs automation comparisons will be made, 

C. Case 3 (minimum systems data FOCC /maximum onboard) 

* The minimum amount of command control, display, and data 
processing equipment will be added to a voice-only centralized 
FOCC that will permit mission feasibility or significantly 
reduce overall costs. 

* Man- in- the -loop vs automation comparisons will be made. 

D. Spacelab Missions 1 and 2 are to be used for this study. 

E. All data transmission to and from the ground will be via the TDRSS. 

F. One centralized FOCG at Johnson Space Genter (JSC) -will be assumed 
as the baseline for all cases,. - 

G. Assume the crew size is variable for each case, 

H. For all caries, the onboard control and display shall be as defined by 
the Payload Specialist Study'*' for the aft flight deck (AFD) and by the 
Spacelab Accommodations Handbook^ for the Spacelab module. 

I. Accommodations for onboard data processing requirements exceeding 
the capability of the Spacelab Command and Data Management 
System (CDMS) shall be assumed as part of each instrument design 
for all cases. 

J. Assume Caution and 'Warning (C&W) is constant for all cases. 

K. Verification Flight Instrumentation (VFI) and related operations are 
to be considered as a high-priority experiment, however, it is not 
to be the prime design driver. 

Xi. All costs are Rough Order of Magnitude (ROM), normalized to 
FY *77 dollars. 


1. Payload Specialist Station Study, Martin Marietta Corp. , Report 
MCR-76-403, November 1976. 

2. Spacelab Accommodations Handbook, Review Issue, FDR-B, 1976. 



M. Costs will be determined as increments to a baseline system. The 
baseline system is considered to be the current system design and 
FOCC/NASCOM facilities presently planned for early Spacelab 
missions . 

N. POCC facility deletions that are possible for Case £ {minimum POCC) 
and Case 3 (minimum systems POCC) "will not be costed. 

O. Onboard equipment reductions will not be considered for any of the 
three cases. 

F. Utilization or operating costs will be expressed in man-hours. Man- 
loading will include both Government and Contractor services, 

Q, The basic operations and maintenance of POCC facilities, communi- 
cations, and ground data systems are assumed to be constant for all 
cases and are provided wholly by JSC as the POCC host. 

R, Real-time software used in POCC computers will be developed, 
maintained, and funded by JSC, Software for offline analysis and 
software for user-provided equipment will be user-provided, main- 
tained, and funded, 

S, Computation support for payload activity replanning will be performed 
on an MSFC computer using terminals located in the POCC and the 
software system used for px-emission planning. 

T, Continuous POCC manning is required throughout the mission for 
all cases, but manning levels are dependent upon specific payload 
activity requirements. 



Section 2 
APPROACH 


The general approach followed for this study is summarized in Figure 1-2-1, 


CR20-III 



Figure 1-2-1, Study Flow 


2. 1 TASK 1 - INDIVIDUAL EXPERIMENT ANALYSIS 

An analysis of each experiment was conducted to develop an operating plan 
for each of the three cases. Individual experiment and CDMS interfaces 
were defined for each experiment using existing documentation and consulta- 
tion with cognizant investigators and payload engineers,. The onboard and 
ground personnel and hardware/ software support requirements were identified 
Potential instrument design and Spac el ab support system impacts were also 
identified. 


2. 2 TASK 2 - INTEGRATED MISSION ANALYSIS 

Based on NASA/MSFC-supplied mis sion experiment timelines, each of the 
individual operating plans for each of the three study cases developed in 
Task 1 were integrated to identify mission and/or support system total 
demands. Crew demands including VFI were assessed along the entire 
timeline. Total demands were assessed by reviewing the entire timeline 
to select certain critical high- activity periods for more detailed assessment. 
System impacts were identified and integrated mission support requirements 
were established for each study case (e. g. , crew size, FOCC manning, 


downlink data rates, uplink command rates, TV transmission, etc. ). 
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2. 3 TASK 3 - SYSTEMS DEFINITION 

Based on the results of the integrated mission analysis (Task 2), impacts on 
baseline hardware and software design were described for both the onboard 
systems and the POCC. 

2. 4 TASK 4 - COST ANALYSIS 

A cost work breakdown structure was prepared with associated costing ground 
rules and assumptions* Using the system definition results of Task 3, a cost 
analysis was performed in accordance with the cost work breakdown structure 

2. 5 TASK 5 - PROGRAM INTEGRATION AND RECOMMENDATIONS 
All findings were summarized, both quantitative and qualitative, for each 
study case. 



Section 3 
STUDY RESULTS 

3. 1 INDIVIDUAL EXPERIMENT ANALYSIS 

Each individual experiment on Spacelab 1 and Spacelab 2 was separately 
analyzed to (1) identify currently defined characteristics and planned opera- 
tions; (2) define an experiment control, display, and data management base- 
line (Case 1) including CDMS interface and operations; (3) define variations 
to this baseline for Case 2 and Case 3; and (4) assess the individual experi- 
ment impacts, by case, on the flight crew, POCC staffing, and planned 
hardware and software. The sources for data on the experiments included 
(1) the mission Strawman documents, (2) SSPD documents, (3) mission 
Announcements of Opportunity (AOs); (4) various studies on specific payloads 
or disciplines involved, and (5) telecons with specific investigators or lead 
engineers involved in the conceptual design of planned experiments or 
instruments. In addition, MDAC experience with Skylab experiment opera- 
tions and data management, tempered by the STS and Spacelab operation 
guidelines and policies, were used as appropriate. Where no clear or common 
definition of an item was available, estimates or assumptions were made 
consistent with the best or most recent descriptions. This was alsc the 
approach used, where necessary, in adapting the definitions to off-nominal 
cases. 

3.1.1 Spacelab 1 Individual Experiment Analysis 

The twelve Spacelab 1 experiments analyze^ are presented in Table 1-3-1 
along with the basic location of their hardware components, general pointing 
requirements, and basic objectives. As indicated, Spacelab 1 contains both 
NASA and ESA experiments located in the (long) module and on the pallet. 
Pallet-mounted instruments generally have a control and display panel 
located in a rack in the module. Half the experiments are rack only, one 
experiment is mounted (when operated) at the modiile viewport, and one is 
deployed (when operated) from the module airlock. The experiment set is 



Table 1-3-1 
SFACELAB 1 EXPERIMENTS 


Experiments 

Locations 

Module Pallet 

STS 

Pointing 
O fcher 

Basic Objective 

1> AF-09 Electron Accelerator 

Rack (C&D) 

Inst 

X 


Active sounder of mag- 
netosphere and 
atmosphere. 

2. AF-13 ELL TV 

Rack (C&D) 

Inst 

X 

±45 ° Z-Cone 

AP-09 sensor plus 
extended objects viewing. 

3. ST-31 Drop Dynamics 

Rack 

. — 

• — 

' ■. — 

Drop dynamics. 

4» EO-Ol Cloud Physics Lab 

Rack 


— 

' — 

Cloud microphysics. 

5. LS- 13 Minilab 

Rack 

— 

*— 

— 

Cell, tissue /blood, and 
urine/frog otolith. 

6. APE-01 LIDAB. 

Rack (C&D) 

Inst 

X 

Align 

Active atmosphere 
sounding. 

7. SPE-80/85 Space Processing 

Rack 




Alloys, fiber /crystals/ 
pure metals /super- 
conductors. 

8. SPE-01 Electrophoresis 

Rack 

— 

. — 

— 

Pure chemical and bio- 
logical specimens. 

9. EOE-Ol Metric Camera 

Viewport 


X 

Z- Steer 

Earth mapping (targets). 

10. APE-07 IR Radiometer 

Rack (C&D) 

Ins t 

X 

±60 B Y Z-Scan 

Passive atmospheric 
sounding. 

11. STE-10 Heat Pipe 

Rack 



— 

Heat pipe technology. 

12. ASE-01 Wide Field Galactic 
Camera 

Airlock 


X 


Extended objects 
mapping. 


multi disc ip line; four (33%) are atmospheric and space physics sounders or 
sensors, one other (EO-Ol) is highly oriented to atmospheric physics, and a 
sixth (ST-31) is also physics oriented. Two experiments are in space 
processing, one is in life science /biomed, and one each is in earth mapping, 
astronomy mapping, and space technology (heat pipe). Six (50%) of the 
experiments require some degree of STS pointing and orientation, and three 
of these require some degree of additional pointing control (pointing, steer- 
ing, and/or scanning). 

Table I-3-Z briefly summarizes some operating characteristics of these ' 
experiments, including their primary control source and crew functions for 
the baseline case (Case I). Typical run times are presented for each 
experiment. The run times include calibration as well as actual data gather- 
ing time, but does not include any set-up or refurbish time; rather, each is 
representative of the time which requires continuous or near continuous 
monitoring and control. Some run times (e. g. , APE-01) actually consist of 
a series of rapid data runs (i. e. , 4/second) scanned over the period indi- 
cated. Others, such as ST-31, EO-Ol, SPE- 80/85, and SPE-Ol, consist 
of a precisely controlled experiment process and procedure performed 
(largely automated) over the period indicated. Some are tied to certain 
flight conditions (night side viewing by AP-09, AP-13, and APE-01) or 
targets (EOE-Ol) which are firmly committed to schedule, once orbited. 

As indicated, data rates are all moderate to low except for the numerous 
TV requirements. Most of these can be met by short selected viewing at the 
beginning and/or end of experiments and are primarily operating aids to the 
Principal Investigator (PI) at the POCC in assessing experiment progress 
and contingencies (this is not available for Case Z, by definition) i Several 
prime data records of experiments are on film with little or no real-time 
monitor interface except as provided by sampled TV viewing. For all cases, 
the data stream to ground, except for operational TV, is essentially the same 
and provides the capability to perform postflight analysis. For Case Z, no 
real-time data processing or display is available from this data stream. 



Table 1-3-2 

SPACEBAR 1 EXPERIMENT OPERATIONS CHARACTERISTICS 


Experiments 

Duration 

(b) 

Typical Run 

Data (lcBPS) 
Scientific HK 

Bas eline Cas e 
Control Grew OPS 

T. AP-09 Electron Accelerator (1) (2) 

0.3 

16. 2 

1 . 2 

POCC 

Activate 

2 AP-13 LLL TV (1) (2) 

0.3 

TV 

0.2 

POCC 

Activate 

3. ST-31 Drop Dynamics (3) 

0.5 

Film/TV 

1.3 

Program Seq 

Support 

4. EO-0 1 Cloud Physics 

2.0 

1.6/ Film 

0. 6 

CDMS Program 

Activate 

5: LS- 13 Minilab 

0.7 

7/TV 

T. 0 

CREW/CDMS 

Operate 

6:. APE-01 LIDAR (1) (2) 

0.5 

54.4 

4. 0 

POCC 

Activate 

7. SPE-80/85 Space Processing (3) 

2. 0 

Film/ TV 

1.2 

Program Seq 

Support 

8. SPE-01 Electrophoresis 

0. 5 

3/Film 

1.0 

Program Seq 

Support 

9. EOE-Ol Metric Camera (2) 

0 . 1 

Film 

0 . 2 

CREW/CDMS 

Operate 

10. APE-07 IR Radiometer (2) 

0.5 

69.0 

1 . 0 

POC C / CDMS 

Activate 

11. STE-10 Heat Pipe 

4.0 

0.3 

0. 2 

POCC/ CDMS 

Activate 

12 . ASE- 0 1 Wide- Field Galactic 

. 0.2 

Film/ TV 

0 3 

CREW/CDMS 

Operate 

Camera (2) (3) 

VFI I and II J 

(Assumed Constant) 60.4 

(Assumed as Avail) TV 


MCC/CREW 
(No POCC IF) 

Support 

Operate 


(1) These experiments are operated on night side only 

(2) These experiments require STS pointing 

(3) TV coverage limited to selected samples only (primarily operations assess aid) 


For the baseline case, primary experiment control and monitoring are 
centered in the POCC except where special factors require or favor onboard 
control (POCC monitoring is used in all Case 1 experiments). In three 
cases, onboard control is exercised by preprogrammed sequencers contained 
in the experiment itself; for Case 1 these are subject to program update 
command link from POGC, prior to each run activation. While these could 
perhaps be more easily effected by the crew (via POCC voice and text uplink) 
directly on the experiment panel, it was elected to apply Case 1 guidelines 
for maximum POCC control/minimum onboard operations. However, in all 
cases, experiment activation (initial set up and turn-on) was considered pri- 
marily an onboard crew function. 

For one experiment (EO-Ol), because of the complexity of operation 
(including control feedback and use of the CDMS) and run duration, it was 
elected to maintain primary control onboard, even. for Case 1. In addition, 
the minilab and cameras require significant crew manual operations and 
support and are baselined for onboard control, although the POCC contributes 
by monitoring data and TV and advising. 

In addition to the 12 experiments shown here, there are some eight different 
groups of verification flight test (VFT) instruments including module and 
pallet instruments. Most of these are passive or require little crew support. 
They were not individually analyzed; however, their impacts on the data link 
and on the crew work load were taken into account in the integrated analysis. 

3. 1.1.1 AP-09 Electron Accelerator 

This experiment consists of a high-voltage electron beam discharged into 
space to evaluate interaction with the ambient and perturbed plasma, length 
of magnetic field lines, magnetospheric electric fields, and induced atmos- 
pheric emissions. A variety of sensors (assumed fixed in the pa.yload bay 
for Spacelab 1) are used, including a vector magnetometer, low-light-level 
TV (LLL TV), and electrostatic potential analyzers. Also included are high- 
pressure nitrogen supplies which vent a plume of gas in the path of the elec- 
tron beam for viewing by the LEL TV (AP-13). Figure 1-3. 1 shows the 
arrangement of the AP-09 main elements interfaced to the CDMS. Data 



ORBITER 


SPACELAB MODULE 

EXPMT RACK 


PALLET 



PAYLOAD 

BAY 


A P-1 3 

PALLET 

ELEMENT 


Figure 1-3-1. Spacclab 1 AP-09 Electron Accelerator and AP-13 Law Light Level TV, Case 1 Control and Display/Data Processing 


















functions and control operations are also indicated for Case 1. Experiment 
AP-13 (LLL TV), which works closely with AP-09, is also shown. 

Operation of the AP-09 experiment requires night side conditions and 
orientation by STS with respect to the magnetic field and velocity vector. 
Alignment with the magnetic field is monitored by the Spacelab experiment 
computer through the magnetometer signals and controlled by forwarding 
pointing requests to the STS general purpose computer (GPC). Closed-loop 
pointing control is maintained onboard, even for Case 1, as the most prac- 
tical approach to maintaining alignment during discharge. It is assumed that 
onboard override (manual or general purpose computer) or ground command 
(from MCC) is available if needed. Activation of AP-09 is initiated onboard 
by a payload specialist at the AP-09 C&D panel (set up and turn-on). 

For Case 1, POCC uplinks commands (through MCC) to the experiment 
computer to load in the AP-09 programs out of mass memory. POCC then 
initiates the AP-?09 programs on coordination and verification by the onboard 
crew. AP-09 operations and housekeeping are monitored at the POCC by 
the AP-09 systems engineer; onboard display and monitoring is available 
to the crew as an option or backup only. Experiment control and beam 
discharge is assumed to be commanded from the POCC (involves coordination 
with onboard crew, STS, and AP-13), Sensor scientific data is downlinked 
directly through the high-rate multiplexer (along with the housekeeping data) 
to the POCC. Magnetometer data required for STS alignment is also supplied 
through this data bus to the experiment computer. The downlinked scientific 
data is monitored by the AP-09 PI and the system scientist to assess opera- 
tions acceptability. Experiment computer functions are indicated along with 
estimates of the computer operations per second and memory requirements 
(AP-09 and AP-13 combined). These estimates were based on the required 
computer functions and the number of parameters, sample rates, and/or 
data rates required. With this approach, onboard crew work load, primarily 
activation, was minimal (0. 2 man) when averaged over the run time. 
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For Case 2, the major changes are (1) deletion of POCC command uplink 
(operations are centered onboard at the data display unit/keyboard 
[DDU/KB] and AP-09 panel); (2) data bus access of AP-09 science data (all 
sensors) for onboard automated monitoring by the experiment computer 
(data is still directly downlinked through the high- rate multiplexer [HRM] for 
postflight analysis, but onboard monitoring is limited to a gross assessment 
as to sensor output); and (3) in conjunction with AP- 13, TV display of AP-09 
plume discharge onboard to the payload specialist for comment and assess- 
ment to the POCC PI (voice-link only). This TV image is still downlinked 
for ground record as vital to postflight analysis of AP-09 (or AP-13) experi- 
ments; however, by definition, it is not available at the POCC in Case 2, 

POCC and PI control can still be exercised to a limited degree through voice 
uplink, or preferably by text if complicated, to the onboard payload specialist 
for input at the DDU/KB or AP-09 panel. The scientific monitor function 
imposed on the experiment computer increases its load significantly but still 
within capacity. The load (42 K OPS, 30Kword) is total (all programs and 
subroutines) for AP-09 and AP-13; actual load at any instant may be signifi- 
cantly less. The automated monitor function was provided to minimize the 
monitoring work load imposed on the crew since crew work load, even with 
added crewmen, appears critical for Case 2. Even with this approach, AP-09 
was estimated to require almost a full-time crew (0. 9 man) due to activation, 
TV monitoring, voice link, and control operations. 


Case 3 is similar to Case 1, again, but with (1) AP-09 command and control 
operations onboard and (2) housekeeping and scientific data, including AP-13 
TV image, available at the POCC for real-time monitoring and assessment. 
The required onboard operating programs add only a moderate load on the 
experiment computer (estimated total is 13 K words, 12 K OPS maximum). ; 
Onboard crew monitoring is minimized, as in Case 1, by effective use of the 
POCC. However, the increased onboard control function increases crew work 


load to 0. 8 man (almost as high as Case 2, although at a higher level of con- 
fidence in a successful operation). 


There is no significant onboard hardware differences between cases, and no 
additions are required to the baselined ^OCC configuration. Significant soft- 
ware differences occur, hdwever, primarily for Case 2 onboard and for Case 1 
at the POCC. 
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Estimated POCC staffing requirements are shown in Table 1-3-3. 


Table 1-3-3 
AP-09 POCC STAFF 


Function 

1 

Case 

2 

3 

Overall assessment/command 

1 

1/2* 

.. 

Monitor scientific data 

1/2 

— 

1/2 

Monitor AP-09 /AP-13 TV 

1/2 

1/2* 

1/2 

Monitor housekeeping data 

1 

1* 

1 

Total 

*Fer voice link comments only 

3 

2 

2 


POCC hardware utilization is maximum for Case 1 (3 CRTs, 1 TV, 1 com- 
mand panel) and can be met by the planned configuration. 

3. LI. 2 AP- 13 LLL TV ' 

This experiment is used in combination with the AP-09 electron accelerator 
and serves as an aspect camera for that experiment. It is also used to detect 
faint and extended objects in the atmosphere (aurora and airglow). It may 
also be used as a target search for the wide field galactic camera (ASE-01). 
LLL, TV experiment characteristics and operations applicable to this study 
are: 

• Mounted on a small pointing mount (±45° Z) on pallet. General STS 
orientations earth, stellar, and magnetic field required during 
operation. 

• Data is analog video (4. Z MHz). 

• Housekeeping measurements (<1 kBFS) are monitored during 
operation. . 

• Experiment is shut down between runs. 

• No set up required after initial activation (unlock, checkout). 

• Requires pointing mount operations in conjunction with AP-09 beam 


viewing, support to ASE-01 target search, and AP-13 unique 
(atmospheric phenomena). 



• Crew involvement is required during data gathering (monitoring and ; 

pointing) (Cases 2 and 3). 

• POCC involvement is required during data gathering (monitoring for 
Cases 1 and 3, and pointing for Case 1. 

• Real-time visual analysis is required on intermittent basis. 

£ Deactivation requires lock up and securing mount prior to deorbit. 

In Case 1, this experiment will be controlled by ground commands; the point- 
ing mount will be slewed., and the TV camera activated. The interfaces with 
the CDMS are shown in Figure 1-3-1. The ground commands will be proc- 
essed by the onboard computer and routed through appropriate remote 
acquisition units (RAUs) to the end items. Housekeeping data will be moni- 
tored by the AP-13 system engineer The video signal will be monitored by 
the PI. Pointing will be controlled from the POCC by the appropriate PI 
(AP-09, AP- 13, or ASE-01). The housekeeping data and the video signal 
will be monitored intermittently by the flight crew, especially during TDRS 
data gaps. •. 

In Case 2, the pointing mount and experiment will be controlled and the 1 

housekeeping data and the video will be monitored by the flight crew. The - 

video will be downlinked for postflight analysis. The control and monitoring j ' 

will be accomplished at the DDU/KB or at the dedicated experiment panel. 

Voice link with the appropriate PI at the POCC will be used to assess and ! : 

direct the video viewed by the crew. 

In Case 3, it is recommended that pointing mount and experiment control be 
accomplished by the flight crew and that the housekeeping data and video be 

transmitted to the ground for monitoring and analysis by the AP-13 system j 

engineer and the appropriate PI. The flight crew also monitors video in sup- . .. ! 

port of control and pointing operations, rapid response to AP-09 operations, , j 

and response to PI direction. . j 

The activities of all three cases can be accomplished with no hardware j 

additions (assumes miniaturized pointing mount analog pointing panel - 

can be used for AP-13 pointing by POCC). The only software changes will j 


require additions to POCC software capabilities, in Case 1, to control the 
pointing mount and experiment. 



Flight crew utilization is low (estimated at 0, 2 over the run time) in Case 1. 
For Gases 2 or 3, because of the increased onboard monitoring and control, 
crew utilization is almost full-time during runs. POCC personnel supporting 
the experiment are indicated in Table 1-3-4. 

Experiment computer functions are indicated in Figure 1-3-1 along with 
estimates of the computer operations per second and memory requirements 
(combined AP-09 and AP-13). These estimates were based on the required 
computer functions and the number of parameters, sample rates, and/or 
data rates required. With this approach, onboard crew work load (primarily 
activation) was minimal (0. 2 man) when averaged over the run time. 


3. 1. 1.3 ST-31 Drop Dynamics 

This experiment consists of single rack-mounted equipment to generate drop 
specimens, inject these specimens into a test chamber, and excite and posi- 
tion them acoustically (three drivers with variable frequencies, power levels, 
and phasing) while monitoring their physical dynamic properties (oscillations, 
shape, fission, etc. ). Each experiment run is primarily controlled by a pre- 
programmed sequencer in the experiment hardware (magnetic tape being 
considered) and data are recorded on three orthogonally positioned film 
cameras. This includes film edge record, via light- emitting diodes (LEDs), 
of run number, time, and test conditions. Manual operations include drop 


Table 1-3-4 
AF-13 POCC STAFF 




Case 


Function 

1 

2 

3 

Overall assessment and command* 

. : 1 

' l 

1 

AP-13 unique experiment video** 

1 

- 

1 

Monitor housekeeping data 

- 1 . 


- ; 

Total 

3 

■ T 

: 2- ' 

*Has video display also in Cases 1 and 3 (Case 

i 2 voice- only) 


wNot required with AP-09 operations 
AP-09 PI). 

(monitor 

function met by 




i 



i 


fluid changes and servicing, film loading, test chamber cleaning, and control 
panel and TV camera set ups. Limited direct viewing or TV coverage of the 
test chamber is provided to assist in real-time assessment and subsequent 
run reprogramming. 

Current design goals call for a self-sufficient experiment package with 
minimum functional interfaces with Spacelab (i. e. , no data nor CDMS, no 
controls, and only power, thermal, acceleration, and timing inputs). All 
controls and displays are onboard with voice support from ground; experi- 
ment data is returned on film. 


Figure 1-3 -2 presents the ST-31 and CDMS interface for Case 1. To operate 
from the ground, additional flight hardware features would be required, i. e. , 

A. Design changes to allow remote panel controls /displays. 

B. Basic CDMS components and interfaces (RAU, software). 

C. Optics to permit simultaneous TV and film camera. 

D. TV camera mount and connection. 

Also for Case 1, flight crew support would still be required to change film, 
clean chamber, etc. Film would still be primary data source, POCC soft- 
ware, data, and TV systems would also be required, 

For Case 2, the data bus link is still required to minimize the crew monitor- 
ing requirements The TV may be eliminated in favor of direct viewing, 
if possible, for the voice link comment and assessment to the FI (no TV at 
POCC). In addition, program changes need to be directly entered by the 
onboard crew (via DDU/KB or, preferably, the ST-31 C&D panel) since 
command uplink is not available from the POCC. It is possible that ST-31 
CDMS interface may be eliminated for Case 2 if crew monitoring at the 
rack is permitted; however, adding simultaneous panel monitoring to 
chamber viewing plus the manual operations, may present an excessive 
demand on crew time line. 

Data downlink via HRM for postflight analysis is not required in Case 2 since 
the same data is available on the ST-31 film record. 
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Figure 1-3-2. Spacelab 1 ST-31 Drop Dynamics, Case 1 Control and Display/Data Processing 
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Figure 1-3-3 presents the ST-31 and CDMS configuration for Case 3, This 
is near the nominal configuration (currently planned) v/ith no direct interface 
tr the CDMS although some method of providing flight timing is required. 

This might be provided by a minimal input from another experiment RAU, 

TY viewing and downlink to the POCC PI is provided, however, as a means of 
enhancing experiment operations and success by allowing real-time assessment 
and potential program updating (via voice and text uplink-directed crew 
manual input to the ST-31 C&D panel). The only real-time monitor available 
to POCC is the selected video viewing. Prime experiment record, for post- 
flight analysis, is the returned film record. The flight crew may provide - 

occasional ST-31 panel monitoring and comments (voice) to POCC as 
requested. 

Flight crew utilization is estimated (over the run time) at 0.4 mei* for Case 1. 
full time for Case 2, and 0. 6 men for Case 3. POCC personnel estimates 
are similar to that presented for AP-09 at three, two, and two for Cases 1, 

■ ■ ■ 

2, and 3, respectively. " ' . 

No new hardware procurements are required in any case as the added RAU >•-. 

and connectors for Cases 1 and 2 are assumed available from currently 

authorized inventory. The minor experiment equipment features such as 

RAU interface, TV mount, etc., are assumed within the currently conceived 3 

equipment scope, POCC requirements can b e met by the baseline. 

Onboard software requirements are maximized for Case 2 (assuming CDMS 

monitoring), and POCC software requirements are maximized for Case 1. ! 

Case 3 requires no CDMS or POCC software. ~1 ' ' ' ] 

3, 1. 1.4 EO-01 Atmospheric Cloud Physics . 

This experiment examines the aero-g behavior of gases and aerosols j 

injected into an environmentally controlled test chamber to determine the j 

atmospheric microphysics of cloud formations, dispersion, condensation, j 

thermal transfers, etc. Operation consists of both manual and automated 1 

functions interspersed over 'relatively long runtimes: (2 hours)* Data are j 

collected on film and via an electronic data train* Primary control is • 

• ■ ■ j 

• •' . . •' . ■ . •. . ... ' • • ; - ■ j 
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Figure 1-3-3. Spacelab 1 ST-31 Drop Dynamics, Case 3 Control and Display/Data Processing 
















currently centered onboard in the CD MS and requires closely coupled feed- 
back control loops. The flight hardware configuration is the same for all 
cases (Figure 1-3-4); however, POCC control is impractical due to the 
Tracking and Data Relay Satellite (TDRS) loss- of- signal (LOS), experiment 
run time, and close feedback control incompatibilities. For this reason, 

Case 1 is defined with CDMS onboard control of EO-Ol. The POCC can 
monitor and evaluate the EO-Ol scientific and housekeeping data stream, and 
can assess experiment or equipment problems, uplink advice, and program 
changes (for subsequent runs). 

For Case 2, program modifications and updates must be voice and/or text 
uplinked to the onboard crew for manual entry at the DDU/KB (or EO-Ol 
panel, aerosol manifold, etc., as appropriate); however, POCC PI ability 
to assess and manage the experiments -will be severely limited due to lack of 
data, except by voice comments or readouts. Onboard crew time to monitor 
EO-Ol could prove excessive. EO-Ol is already monitored by the CDMS 
computer for housekeeping and program operations, and extending this 
function with additional programs to monitor some of the scientific data for 
gross correlation and limits, will require additional memory and computer 
operations. Otherwise, Case 2 is operated basically the same as selected 
for Case 1, Case 3 is even closer to C.vse 1 in operation, the only difference 
being that no command uplink is available since POCC management or changes 
are via voice and/or text to the crew. The EO-Q 1 data stream is available 
at the POCC as in Case 1. 

Flight crew utilization is lowest for Case 1 (0.4 man) and about the same 
for cases 2 and 3 (0. 7 man) because of the similar control mode and the 
use of the CDMS for automated monitoring in Case 2. 

POCC personnel requirements are estimated as a PI, an experiment scien- 
tific monitor, and a system engineer (three) for Case 1, and a PI and system 
engineer (two) for Cases 2 or 3. 

No new hardware is required in any case. Onboard software needs are 
maximum for Case 2, estimated at up to 47K words memory and 30K OPS 
computing), and are a minimum for Case 1 (Figure T- ^-4). 
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Figure 1-3-4. Spacelab 1 EO-OI Cloud Physics, Case 1 Control and Display/Data Processing 
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3. 1.1.5 LS-13 Minilab 

This is a double rack of life science experiments to investigate body fluid 
redistribution; vestibular function; and cell and tissue growth, development 
and organization, and to develop accurate urine volume measurement sys- 
tems. The operation consists of taking biomedical measurements such as 
blood pressure; collecting, processing, and preserving specimens; and 
st im ulating vestibular function (this is assumed to consist primarily of the 
frog otoligth experiment). Some of the preceding are mostly manual opera- 
tions performed by skilled specialists and could not be readily mechanized 
for remote ground control. Others, such as the cell and tissue growth and 
vestibular stimulation, while subject to ground control, could also be 
easily implemented onboard manually or via CDMS programs. 

Figure 1-3-5 shows the LS-13 and CDMS interface and functions for Case 1. 
One feature, suggested here, is voice tag with the downlinked data, pri- 
marily for postflight analysis convenience since real-time operations will be 
linked by one of the operational voice channels. In addition, it may be 
feasible to downlink LS-13 data available to experiment computer by program 
or direct command via the input/ output (I /O) unit output to the HRM. 

Because of the need for continuous monitoring of certain LS-13 functions, 
especially housekeeping, it was elected to perform these basic functions 
onboard with the CDMS to avoid the problem of TDRS data gaps. In addition, 
this provides a closer control, including automated alert and corrective 
action, over basic LS-13 functions. Housekeeping data is also available to 
the POCC (Cases 1 and 3) for more sophisticated assessment and evaluation 
as necessary. In addition, scientific data is provided in the form of a 7 ltBPS 
data stream (more recent data indicates this may peak at values up to 
100 kBPS) as well as selected TV viewing (the 6 MHz request shown may be 
downgraded to the nominal 4 MHz available in the Spacelab system). In any 
event, film record is available on return for postflight analysis. 

For Case 2, the data stream downlink is the same except for no TV (POCC 
is limited to voice only and data stream is for postflight analysis). Com- 
puter software estimate is increased to 24K words to provide increased 
automated monitoring of data to minimize crew monitoring requirements. 
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Case 3 is the same as Case 1. Flight crew requirements (1.3 men during 
LS- 13 operations) are estimated as the same in all cases since computer 
monitoring in Case 2 is assumed to supplant POCC monitoring functions. 

POCC personnel requirements are similar to that estimated for EO-Ol 
(i. e. , three, two, and two for Cases 1, 2, and 3, respectively). 

Hardware is the same in all cases. Software is maximum for Case 2 onboard 
and for Cases 1 or 3 on the ground, 

3.1. 1.6 APE- 01 LIDAR 

This experiment uses equipment for sounding the atmosphere in the optical 
band by laser backscatter techniques in order to define mean structure, tem- 
peratures, winds, and distribution of aerosols, atoms, ions, and gases. 


The low-power (1-Joule pulse) laser limits operation to night side passes; 
repetition is four soundings per second once the instrument is aligned and 
calculated. Possible misalignment requires adjusting the laser optics rela- 
tive to the receiver. Calibration is achieved by adjusting dye flow to the 
tunable dye laser and to a reference opacity and density (reference sources 
assumed provided in experiment). Once initiated, this calibration can be 
largely automated, as can the operation (STS pointing, laser operation, dye- 
flow calibration); however, man monitoring and support appears warranted, 
at least on early missions. Housekeeping functions involve power supply and 
conditioning and cooling; these are also largely automated in the experiment, 
but should be monitored by the CDMS with man as occasional monitor, backup, 
and contingency. Scientific data is produced in rapid bursts (typically 50 msec 
Figure 1-3-6 presents the APE-0 1 and CDMS configuration and functions for 
Case 1. 


Primary control and monitoring is executed from the POCC. The flight crew 
activates the AP-09 panel and performs any required p re ope ration checks. 
POCC commands the necessary programs into the onboard computer as well 


as directs commands to AP-09. The onboard computer monitors status and 
hous ekeeping as well as forwards uplink commands and formats hous ekeeping 
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Figure 1-3-6. Spacelab 1 APE-01 LIDAR, Casel Control and Display/Data Processing 


















data for onboard display (for activation and preoperation checks, occasional 
operations are displayed on demand). APE-09 scientific data and house- 
keeping data is downlinked directly through the HRM to the POCG for moni- 
toring and assessment. 

For Case 2, APE-01 control and monitoring is centered in the CDMS 
experiment computer. APE-01 pointing requirements are determined from 
the GPC for execution. Onboard work load is increased for calibration and 
APE-01 operating assessments; this is partly offset by providing a gross 
scientific data assessment (sensor limits, output, and logic) to the experi- 
ment computer functions. These added functions increase the estimated 
total onboard computer load to 84K OPS and 50K words (not all required 
simultaneously). 

Onboard crew utilization is increased from 0. 4 man (Case 1) to full-time 
(1. 0). This is due to the increased onboard calibration and control, control 
and monitoring of pointing requirements, and monitoring and assessment of 
the APE-01 and CDMS operations. Total data stream is still directly down- 
link, via HRM, for postflight analysis. 

Case 3 maintains onboard calibration and control, including determination of 
pointing requirements, but scientific data monitoring and assessment decreases 
to about 0. 6 man - with minimum onboard monitoring or involvement, once a 
run is fully initiated. Onboard computer operations decrease to an estimated 
total APE- 01 load of 16K OPS and E3K words. 

Onboard hardware and configuration is the same in all cases and maximum 
POCC requirements (Case 1) of one scientific display and one housekeeping 
display are within the baseline. POCC software is maximum for Case 1. 

POCC personnel estimates are two, one, and one for Cases 1, 2, and 3, 
respectively. 

3. 1. 1.7 SPE-80/85 Space Processing 

This experiment provides three furnace facilities for research on processing 
alloys, particle and fiber reinforced materials, and dispersed superconduc- 
tors, and purification of metals in a controlled zero-g environment. Specimens 



are positioned and melted in a closely controlled environment of inert gas. 

In some cases, the melted specimen is mixed or positioned by acoustics, 
Specimen selection; specimen insertion, mounting extraction, and stowage; 
and panel set ups require the flight crew, but other operations are automated 
by a programmable experiment sequencer. The preprogrammed experiment 
sequencer would control the furnaces heating, gas composition and pres- 
sures, cooling flow, time line, acoustic or mechanical positioning and 
mixing devices, and data collection. These would include nominal value 
housekeeping programs and specific experiment programs. This would be 
subject to reprogramming {program update) onboard via command uplink 
(Case 1) or direct crew entry (Cases 2 or 3) at either the CDMS or 
SPE- 8 O /80 C&D panel. Reprogramming would nominally be limited to 
setting of certain key program parameter values (temperature profile, run 
time, pressures, etc.) in an existing program. 


Scientific data are collected on film and in specimens, with supporting 
engineering data on equipment performance and test conditions (temperatures, 
time, pressures, accelerations, and acoustics) supplied via CDMS data 
train. Individual experiment runs vary from as low as 1 hour to as long as 
24 hours, with a typical run time of 4 hours. Up to three runs may proceed 
simultaneously by using all three furnaces, however, nominal operation 
would have only one or two runs at a time. 


Figure 1-3-7 shows the SPE-80/85 elem^' .s and their interface and functions 
with the CDMS for Case 1. As indicated, a TV interfac e is shown for down- 
linking news of the specimens to the POCC for experiment assessment and 
update. Current ESA design does not appear to provide direct viewing into 
a furnace during operation, in which case, TV downlink would be limited to 
the selection aid installation process and the postrun extraction and examina- 
tion. This would still be highly useful to the POCC PI in assessing experi- 
ment results and subsequent operations. 

SPE-80/85 is currently a semiautonomous design with limited operations, 
status monitor and data acquisition, imposed on the CDMS. For Case 1, this 
includes a POCC command uplink capability, including updates of the 
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SPE-80/85 programmer. For Case 2, the TV downlink is not available to the 
POCC. Experiment observation is limited to the onboard crew (verbal link 
to POCC) prerun and postrun descriptions of specimens. Real-time viewing 
of specimen runs depends upon furnace viewports accessible to the crew or 
to closed- circuit television (GCTV), These would be of more limited value 
since onboard crew work load would not permit more than occasional moni- 
toring. Program updates from POCC voice, or text, uplink would be entered 
by the crew at the DDU/KB or SPE-80/85 C&P panel. SPE-80/85 data 
stream is monitored by GDMS computer to assure proper operation of equip- 
ment and runs (this is largely redundant to the experiment- contained control, 
but is provided for operations assurance to minimize crew monitor require- 
ments in Case 2). This increases GDMS work load estimate to f>K OPS, 

16K words. 

Case 3 is the same as Case 1 except that control is executed onboard via voice 
or text uplink. 

Crew utilization is estimated at 0, 3 man for Case 1 (primarily the necessary 
manual operations), 0. 7 for Case 2 (visual monitoring and conveying to 
POCC by voice), and 0.4 for Case 3 (Case 1 plus control function). 

POCC personnel requirements during runs is estimated similar to that for 
AP-09, i. e. , three, two, and two for Cases 1, 2, and 3, respectively. 

No added hardware requirements were identified. 

3. 1.1. 8 SFE-01 Free- Flow Electrophoresis 

The free-flow electrophoresis facility includes all equipment to perform 
automatic electrophoretic separations for analytical and preparative pur- 
poses. The dimensions of the separation chamb er are in the order of 
180 by 30 by 4 ram (fluid cross section). A buffer solution is pumped 
through the separation chamber by means of a rate- controlled peristaltic 
pump. Biological samples are injected near the upstream end of the 
chamber at a predetermined rate. An electrical field is applied perpen- 
dicular to the buffer flow which deflects the samples at different angles 
depending on their electrophoretic mobility. At the downstream end of the 
separation chamber, the fraction obtained is collected by a series of small 
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tubes into a compartmented storage rack. The results maybe observed 
visually by an optical window. Data recording is possible either photographi- 
cally or via a special optoelectronic data acquisition device which generates 
an electrical signal derived from the concentration of light- absorbing 
material (fractions) along a cross section of the separation chamber. 

In addition to the basic equipment described, some auxiliary equipment is 
necessary to support the main function. 

A. In order to remove gas bubbles generated by electrolysis, a separate 
purge fluid loop is provided. To prevent gas from penetrating into 
the buffer flow, both electrodes are separated from the active 
volume by an ion exchange membrane. 

B. As live biological samples are used, special provisions must be 
made for temperature control. The separation chamber is cooled 

by a liquid cooling loop to withdraw the heat generated by electrolysis 
processes. As chamber low temperatures (+5°C) are required, 
active cooling is provided. 

C. In order to keep the samples alive for the mission duration, the 
sample fraction storage volume is cooled to an average temperature 
of ±2°G. As continuous cooling, even during ascent and descent, is 
required, a dedicated battery module has to be used. 


Figure 1-3-8 shows the SPE-01 and GDMS elements and functions. Crew 
operations include set up and reduction of buffer fluids and flow rates; set 
up and installation of fraction collection; activation of buffer flow which is 
automatically controlled; selection and injection of samples into the flows; 
monitoring of separation through density scan readouts or direct visual, if 
feasible; isolation, remc i, and storage of collected fraction rack; clean 
up and purge; and film change. 

During the actual flow run, the process (flow rate, purge loops, voltage level, 
temperature, etc.) is controlled by the selected experiment program (DDU/KB 
or SFE-01 C&D panel) in the experiment sequencer. Experiment data is 
provided to the CDMS for monitoring housekeeping and for format and display 
at the DDU; it is also directly downlinked through the HRM. 
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Figure 1-3-8. Spacelab 1 SPE-01 Free-Flow Electrophoresis, Case 1 Control and Display/Data Processing 
















For Case 1, command uplink to SFE-01 is provided to adjust and modify the 
run per the FOCC PI assessment of downlinked data. For Case 2, program 
modifications are entered directly via DDU/KB or SPE-01 C&D panel per 
FOCC PI voice and/or text direction. The experiment demands a large 
degree of crew support despite automated run control. To minimize crew 
demands for onboard monitoring (Case 2) the CDMS computer is used to 
monitor the scientific output (density counts, etc. ) as well as key house- 
keeping parameters. This increases computer work load to an estimated 
6K OPS, 13K words. Case 3 is like Case 1 except POCC PI does not have 
direct control access (crew entry onboard through CDMS or SPE-01 C&D 
panel). 

Crew utilization is estimated at 0. 5 man or Case 1, and 0. 8 for Cases 2 
and 3. POCC personnel is estimated at three, two, and two for Cases 1, 2, 
and 3, respectively. No hardware additions are required in any case. 

3. 1.1.9 EOE-01 Metric Camera 

This experiment utilizes a high- resolution, geometrically accurate camera 
(visible and near) for earth mapping and for calibration reference for the 
more experimental earth-imaging sensors. The camera is gimbal- mounted 
at the optical viewing window during operation and is removed and stowed 
when not in use. Interval timing and slew control is by CDMS computer 
which requires Orbiter state vector data. De stowing, installation, film 
loading, panel setups, calibration, removal, and restowing are manual. 
Actual operation for data-taking can be manual but will normally be auto- 
matically timed with target acquisition and pointing by the CDMS computer 
update from the STS state vector. The flight hardware configuration 
(Figure 1-3-9) remains the same for all cases, with software and manpower 
emphasis being the primary differences. 

Data consist primarily of hous eke eping and status (temperatures, film number 
power levels, time, optics settings, and gimbal angles). It is suggested that 
some of these key parameters be recorded, via LEDs, on the film edge if 
feasible to facilitate correlation. At any rate, this data is monitored and 
operated (primarily targeting, steering, and operation) by the CDMS. The 
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Figure 1-3-9. Spacelab 1 EOE-OI Metric Camera, Case 1 Control and Display/Data Prc cessing 















data is also downlinked through the experiment computer I/O unit via the 
experiment I/O unit line to the HRM or down the 64 kB PS operational line 
to the PCM, if available (data is very low rate). The mode may be prepro- 
grammed or selectable by command. An alternative would be onboard 
record, however, downlinking would be needed to comply with Case 1 ground 
rules and allow a degree of camera operation real-time evaluation and 
assessment at the POCC. This mode of data retrieval, which is necessary 
for postflight analysis of the film record, appears suited to the Cases 2 and 
3 also. 

For Case 1, pointing requirements could be determined at the POCC from STS 
state vector projections and provided to the CDMS for execution; however, 
it would seem more practical to center this function onboard, as in Cases 2 
and 3, and supply the pertinent pointing information to the POCC for monitor 
and record. Primarily, EOE-Ol lends itself to onboard control and operation 
and differences between cases is primarily limited to providing for some 
increases to automated monitoring (2K OPS, 4K words) of camera operation 
and conditions for Case 2 to minimize crew work load. 


Crew utilization is estimated as full-time during manual operations, but 
dropping to 0.1 man (Case 1) and 0. 5 man (Cases 2 or 3) when averaged 
over the run period. Case 1, which depends upon a high degree of POCC 
control as well as monitoring, may be impractical. POCC staffing is esti- 
mated at one man (PI) over the run period in every case. No hardware 
differences were identified. 


3. 1. 1. 10 APE-07 IR Radiometer 

This experiment consists of six identical radiometers used to measure 
atmospheric temperatures and distribution of constituent gases as a function 
of altitude, space, and time. Five of the radiometers share a single limb- 
scanning system, while a reference measurement channel is directed at the 
reference altitude. Each radiometer has two channels except for a CO^ 
reference detector. A black body calibration reference can be imposed on 
each radiometer. Housekeeping and scientific data (70 kBPS) acquired by 
the pallet-mounted instrument is provided to the APE-07 control panel mounted 
in a module rack (Figure 1-3-10). This is then downlinked through the HRM 
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Figure 1-3*10* Spacelab 1 APE-Q7 1R Radiometer, Case 1 Control and Display/Data Processing 

















to the ground for postflight analysis (all cases) and for real-time experiment 
operation monitoring at the POCC (Cases 1 and 3 only). For Cases 1 and 3 
only, housekeeping and operations data (1 kBPS) is routed through an RAU, 
from the APE-07 panel, to the CDMS for onboard monitor and control 
operations. For Case 1, primary control is from the POCC. For Cases 2 
and 3, primary control is onboard from the CDMS which provides an operat- 
ing and scanning program based on experiment pointing requirements and STS 
state vector updates (basic viewing orientation is provided by the Orbiter). 
Calibration is primarily provided onboard through the provided instrument 
references and appropriate CDMS program. 

For Case 1, once activated by the crew, APE-07 will be operated from the 
POCC through call-up and monitoring of the CDMS and APE-07 programs 
and the APE-07 downlinked scientific data stream. For Case 3, these pro- 
grams will be called up and initiated by the crew with POCC primarily involved 
in monitoring and assessing APE-09 scientific data. For Case 2, scientific 
data is also provided to the CDMS for onboard monitoring and verification of 
sensor operations and data limit checks. This will significantly increase 
the experiment computer work load (estimated at 20 K OPS, 27K words for 
Case 2). 

Crew utilization over APE-01 run time is estimated at 0.2 man for Case 1 
and 0.4 for Cases 2 and 3 (increased onboard control). POCC personnel 
include a PI and an APE-07 system engineer for all cases, and an additional 
APE-07 experiment data monitor for Case 1 (PI performs this function for 
Case 3). No new hardware requirements were identified. Some APE-07 
onboard software is required in all cases, but is maximum for Case 2. 

3.1.1.11 STE- 10 Heat Pipe 

The purpose of this experiment is to evaluate the heat transfer capabilities 
of heat pipes in zero-g. Heat is transferred from a source (an electronic 
control box) by heat pipes to a thermal capacitor and then through a one-way 
heat pipe to a heat rejection point (Spacelab water loop). Operation requires 
turning on and off the heat source, via a manual or a preprogrammed automa- 
tion mode, and monitoring temperature distribution through the system, using 
approximately TO monitoring points. Figure 1-3-11 shows the system compo- 
nents and the interfaces with the CDMS. Data functions and control operations 
for Case 1 are also shown. 
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In Case 1, the control of the experiment and the monitoring of the system 
temperatures is accomplished by the ground through the experiment computer 
and appropriate RAU. Data analysis accomplished by the PI in the FOCC 
will identify changes to the test or will determine the requirements for sub- 
sequent tests. The flight crew will support the ground personnel by moni- 
toring experiment operation, especially during TDRS data gaps. 

In Case 2, the control of the experiment and monitoring of the data will be 
the responsibility of the flight crew. This will be accomplished at the 
DDU/KB or the experiment C&D panel. Information downlinked to the FOCC 
via the voic^ link will permit the FI to evaluate the operations and assist 
the flight c rew in evaluating the data. 

In Case 3, the control of the experiment will be performed by the flight crew 
and monitoring and evaluation of the data will be accomplished in the FOCC. 
The flight crew will also monitor the data and, in conjunction with the PI, 
evaluate the operation and determine changes. 

Crew utilization is estimated as 0, 1, 0. 5, and 0. 5 man for Cases 1, 2, and 
3, respectively {increased monitoring and control in Cases 2 and 3). FOCC 
requirements are estimated as two, a PI and an STE-10 engineer, for 
Cases 1 and 3, and one FI for Case 2. 

There is no onboard hardware differences and no additions are required to 
the baseline POCC configuration. 

3. 1. 1. 12. ASE-01 Wide- Field Galactic Camera 

This experiment uses a wide- field {120° by 60°) camera to map extended 
objects, i. e. , galactic equator, zodiac allight, sky background, etc. 
Exchangeable filter modules, automated or possibly manual, with four ranges 
(from 1500 A to 9000 A) are used to gather photographic data. (TV as a 
targeting aid is optional. ) The camera is launched in the Spacelab airlock 
and is deployed outside the airlock before film exposure. The airlock inner 
door is opened only for camera servicing, film and filter changes. Camera 
access and servicing is, of course, manual; data-taking operations can be 



manual or automatic. Camera changeout (various film types) is a planned 
capability. AF-13 may be suitable to provide targeting search. The flight 
hardware configuration (Figure 1-3-12) is the same for all cases. With 
minor software and manpower differences, most control and display is onboard 
with FOCC displays and capability to initiate or sequence data taking for 
Case 1. 

As with EOE-Ol, camera operation ard status is available on a low-rate data 
stream routed to or through the CDMS computer and downlinked, to the FOCC 
in Cases 1 and 3, Via the HRM (Experiment I/O unit input) or 64-kBFS 
operational line as preprogrammed or selected. For Case 2, this data 
stream is available only for postflight analysis, and the TV target search 
option is not available to the FOCC. Onboard crew may use the CCTV, 
possibly with AP-13, to perform this function in coordination with the 
FOCC PI via voice link. 

Crew utilization is estimated as full-time (1. 0 to 1. 5 men) during deployment 
or changeout, and at 0.3 man (Case 1) or 0. 5 (Cases E or 3) over a typical 
run time. Airlock operations imply contingency provisions for EVA. 

POCC requirements are estimated as one man, PI, over the run period in 
every case. No hardware differences were identified. 


3.1.2 Spacelab 2 Individual Experiment Analysis 

A Spacelab 2 experiment complement, consisting of the ten experiments 
listed in Table 1-3-5, was assessed to determine impacts on ground and flight 
mission operations and resultant program costs. These experiments, selected 
from the astronomy, solar physics, and high-energy astrophysics disciplines, 
are installed on two 6-meter ESA pallet trains with controls, indicators, and 
support equipment installed on the Orbiter AFD or in the ESA Igloo. No 
pressurized Spacelab module is assigned to this mission. 


/ 


41 


MCDO/V/VEU, DOUCJLAS 


>iao/ioa ~t~i3NNoac>w 


CR20-II1 


ORB1TER 

I l — 


SPACE LAB MODULE 


PAYLOAD 

RECORDER 



r 

- — > 
r ► 

KU-BAND 

SIGNAL 

PROCESSOR 

s 

v 

A 

• • \r ■ ■ 

L_ 

r 

NETWORK 

SIGNAL 

PROCESSOR 

i _nr 


PCM +~ 

[ MASTER 

. J L . 

MDM 


HIGH-RATE 

RECORDER 


(0,3 kBPS)* 


DDU/KB 


HIGH 

DATA 

RATE 

MULTI- 

PLEXER 


SET UP 
TARGETING 
COMMENTS 
ON OPS 


(0.3 kBPS) 


EXPMT 

I/O 


(0.3 kBPS) 1 


DDU/KB 


EXPMT 

COMPUTER 


MASS 

MEMORY 


• MONITOR 
•CONTROL 

'• FILTER 
CONTROL 

• EXPOSURE 
REQ 

•CAMERA 
OPS — 

•MONITOR AND 
FORMAT 
•1.2KOPS 
*1,6K WORDS 


GPC 

M 

D 

r 

— Ti 


-L- 

RAAB 

— w 


I M; 


1 ■ 1 



! 


MASTER TIME 


VIDEO 

: — ' - — ■ 

■ 


▼ 

TELEVISION 


VIDEO 

SWITCH 

• : 


MONITOR 


RECORDER 


* LOW-RATE DATA ROUTED BY 
EXPMT COMPUTER AS APPROPRIATE 


(SPACE) 


PRIMARY 

OPTICS 

FILTER WHEEL 


CAMERA 

AND 

FILM 


/ EXTEND/ 

RETRACT UNIT ^ 

CMD 

AND (0.1 kBPS) 

DATA , r (HK) 


'ACCESS FOR FILM 
AND CAMERA CHANGES 


TV CAMERA (OPTION) 
(MONITOR AND SELECT 
OBJECTS) 

(REQUIRES MANUAL 
CAMERA CHANGEOUT 
OR USE OF AP-13 
LLLTV) 


CREW OPS 

• SET UP 

• FILM AND CAMERA 
CHANGES 

•FILTER CHANGES 

• AIRLOCK OPS 

• TARGETING' 


-SPACELAB 

AIRLOCK 

• ACTIVATE OPS 

• CONTINGENCY EVA 

• SHUT DOWN/STOW 
k HEATERS 

(THERMAL CONTROL) 


**F!LM EDGE DATA 
RECORD WOULD BE 
USEFUL-SEE 
- EOE-01 COMMENT 


Figure 1-3-12. Spacelab 1 ASE-01 Wide-Field Galactic Camera, Case 1 Control and Display/Data Processing 



















The solar experiments, numbers 1 through 5 in Table 1-3-5, are mounted on 
an Instrument Pointing System (IPS). The far ultra-violet (UV) Schmidt cam- 
era/spectrograph, low-light-level television (LLL TV), and Skylark cos- 
mic x-ray telescope are mounted on a miniaturized pointing mount (MPM), 
while the remaining two experiments are hard-mounted on the pallet. 


Table 1-3 -S 

SPACELAB Z EXPERIMENTS 


1. 65- cm photoheliograph 

Z. Solar monitor package 

3. Soft x-ray telescope 

4. Lyman- Alpha white-light coronagraph 

5. High- sensitivity x-ray burst detector 

6. Skylark cosmic x-ray telescope 

7. ELL, TV 

8. Far UV Schmidt camera/spectrometer 

9. Transition radiation spectrometer 

10. Extreme UV imaging telescope 


Each experiment was analyzed for each of three cases of onboard versus 
ground capability (see Subsection 1. 1), and the impact on experiment opera- 
tions was determined. The interfaces of each experiment with the Orbiter 
and Spacelab CDMS was defined. The Spacelab Z Strawman was used as a 
guide for mission analysis and planning, and a preliminary timeline was used 
to determine experiment activities'. 

The following subsections contain the individual analyses performed for each 
experiment and its operation with the onboard versus ground capability neces- 
sary to support the experiment. 
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3, 1. 2. 1 65-cm Photoheliograph 

This experiment is used to obtain, high-resolution, photographs of solar fea- 
tures. It is used in combination with other solar experiments and also in 
combination with the extreme UV imaging telescope to obtain stellar photo- 
graphs. Sixty- five- cm photoheliograph experiment characteristics and opera- 
tions applicable to this study are: 

• Mounted on IPS. 

• Data is gathered on film. 

• TV camera is part of unit and is used to provide identification 
of what is being observed. 

• Housekeeping measurements (wl2) are monitored during operation. 

• Exp ei'iment is not shut down between runs. 

• Setup includes programming of filters, etc. Experiment runs 
through program automatically. 

• Crew involvement is small during data run (intermittent viewing 
of TV) . 

• No real-time data analysis. 

The operation of the 65-cm photoheliograph in Case 1, where maximum FOCC 
operations are employed, requires that ground control be used to slew the 
IPS to the sun or stellar object, setup the proper filter sequences, and then 
initiate the data- taking cycle. The interfaces with the CDMS is shown on 
Figure 1-3-13. These ground commands will be processed by the appropriate 
Spacelab computer through a subsystem or experiment RAU to the end item. 
The television camera in the experiment will provide real-time presentation 
of the target being observed. All scientific data gathered by the photohelio- 
graph is recorded on film contained within the experiment. Housekeeping 
data, indicating experiment health and program run conditions, will be tele- 
metered to the ground for evaluation in the POCG by the PI. The TV and 
housekeeping data are also available for the onboard flight crew to monitor 
experiment activities in support of ground personnel, espeically during TDRS 
data gaps. 
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Figure J-3-1 3. Spacelab 2 65-cm Photohulio graph 
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Case 2 requires that the command and monitoring activities be accomplished 
by the flight crew. In this case, the uplink IPS pointing commands and experi- 
ment commands will be eliminated, and the downlink TV and housekeeping 
data will not be available in the POCC. Only voice communication will be 
provided between the flight crew and the POCC. The commands and moni- 
toring will be accomplished at the DDU/KB or at the dedicated experiment 
C&D panel, both located in the Orbiter AFD. Interface w J th the IPS and 
experiment Will be as in Case 1, through the appropriate computer and RAU. 
The housekeeping data will be monitored by the flight crew to check the 
health and operation of the experiment while the TV will be monitored inter- 
mittently to verify the target being observed. 

In Case 3, it is recommended that the control of the IPS and experiment be 
performed by the on-orbit flight crew while the major monitoring of experi- 
ment operation and health be accomplished by the PI at the POCC. Flight 
crew support can be provided to the PI, as required, and monitoring will 
be provided during TDRS data gaps. 

The activities of all three cases can be accomplished with no hardware addi- 
tions to the POCC or to onboard systems. Control of the IPS or experiment 
will require no new addition to software onboard; however, additional soft- 
ware must be provided at the POCC to provide control of the IPS. 

Flight crew utilization is slightly less for Case 1 than for the other cases 
because more functions are being performed on the ground; however, in all 
cases, the utilization is low because set-uptime is small (1 to 2 minutes) 
and monitoring is only intermittent. Ground personnel supporting the experi- 
ment would be the same for the three cases except that no pointing engineer 
is required for Case 2. 

3. 1.2. 2 Solar Monitor Package 

This experiment is used to obtain high-resolution solar images and to mea- 
sure solar magnetic fields. During this mission it is used in combination with 
other solar experiments. Solar monitor package experiment characteristics 
and operations applicable to this study are: 
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• Mounted on IPS. 

• Data rate of 50 kBPS. 

• TV camera is part of unit and is used to provide identification 
of what is being observed. 

• Housekeeping measurements (a* 30) are monitored during 
operation. 

• Experiment is not shut down between runs. 

• Set up includes programming of experiment filters, etc. 
Experiment runs through program automatically. 

• Crew involvement is small during data run (intermittent 
viewing of TV). 

• Some real-time data analysis is required to identify presence 
of unique magnetic fields. 


This experiment consists of three sensors (Hydrogen Alpha [HuJ camera, 
an x-ray ultraviolet [xuvj monitor, and a magneto heliograph) which are 
operated simultaneously. 


In Case 1, the solar monitor package will be controlled by ground commands. 
The IPS will be slewed to the sun, the experiment program filters and 
sequences will be set up and the data-taking initiated. The interfaces with 
the CDMS to accomplish these operations is shown in Figure 1-3-14. The 
ground- originated commands will be processed by the Spacelab computers 
and routed through appropriate RAUs to the end item. TV cameras in the 
experiment will provide real-time presentation of the target being observed. 
Scientific data will be downlinked to the POCC and will be evaluated by the 
PI to determine the presence of unique magnetic Helds. The TV and house- 
keeping data will be monitored by the PI to determine proper operation of the 
experiment. The TV and housekeeping data is also available onboard for 
monitoring by the flight crew to support the ground operations, especially 
during times of TDRS data gaps. 


The flight crew activities accomplished in Case 2 are similar to those per- 
formed by the ground in Case 1. The IPS and experiment are controlled by 
crew direction and the TV and housekeeping data are intermittently monitored 
to verify operation. However, the data output of the experiment, a 50 kBPS 
digital stream cannot be continuously processed and analyzed by the onboard 
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Figure 1-3-14. Spacelab 2 Solar Monitor Package 
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computer. This information, in Case 1, can be handled by the ground com- 
puting facility and magnetic fields can be identified. In order to increase the 
experimental scientific return of Case 2 identification of unique magnetic 
fields which might require additional data acquisition, it is recommended 
that a detector be developed as an integral part of the experiment. This 
detector will alert the flight crew of the presence and location of unique 
magnetic fields, and, with the use of the voice link to the PI, permit the crew 
to determine if additional data runs are required. 

In Case 3, it is recommended that the flight crew control the IPS and the 
experiment. The TY, housekeeping data, and scientific data should be down- 
linked to the POCC for PI evaluation as in Case 1. In this case, as in Case 1, 
the addition of the magnetic field detector will not be required. During data 
acquisition, the flight crew will be required to monitor the TV and housekeep- 
ing data on an intermittent basis, mainly during times when there are TDRS 
data gap >i. 

The activities of all three cases can be accomplished with no hardwai’e addi- 
tions to the POCC and only the addition of the magnetic field detector identi- 
fied for Case 2. Control of the IPS or experiment will require no new addi- 
tions to software onboard; however, additional software must be provided 
at the POCC for Case 1 for control of the IPS. 

Utilization of the flight crew is slightly less for Case 1 operations because 
the ground personnel are controlling the IPS and experiment. However, 
flight crew activities are not large in any of the cases, because set up time is 
minimal and monitoring is required only intermittently. 

Ground personnel required to support the experiment are the same for all 
cases except that ho pointing engineer is required for Case 2. 

3. 1. 2. 3 Soft X-Ray Telescope 

This experiment is used to study solar phenomena and physical properties. 

It is used In combination with other solar experiments and contains two sen- 
sors, an x-ray telescope, and proportional counters. Soft x-ray telescope 
experiment characteristics and operations applicable to this study aret 



• Mounted on IPS. 

• Data is gathered bn film. 

• . Housekeeping measurements (rj 9) are monitored during 

operation. 

• Set up consists of a mode selection. Experiment runs through 
program automatically. 

• Experiment is shut down between runs. 

• Crew involvement is small during data run (monitoring). 

• No real-time data analysis. 

In Case 1, the telescope operations will be controlled by ground commands; 
the IPS will be slewed to the sun, the experiment mode will be selected, and 
the data run will be initiated. The interfaces with the CDMS are shown on 
Figure 1-3-15. Ground commands will be processed by an onboard computer 
and routed to the IPS or experiment through the appropriate RAU. Scientific 
data is gathered on film however, housekeeping data will be downlinked to the 
POCC so that the PI can monitor the operation and health of the experiment. 
This housekeeping data is also available for intermittent monitoring by the 
flight crew, especially during TDRS data gaps. 

In Case 2, the command and monitoring activities are accomplished entirely 
by the flight crew and the limited voice interface with the ground will be 
utilized to assist the crew with the operations, The commands and the moni- 
toring will be accomplished at the DDU/KB or at the dedicated experiment 
C&D panel, both located in the Orbiter AFD. Interface with the CDMS equip- 
ment will be, as in Case I, through the appropriate computer and RAU. 
Housekeeping data will be monitored by the flight crew to check the health 
and operation of the experiment. 

In Case 3, the control of the IPS and experiment should be maintained by the 
flight crew while monitoring of the housekeeping data should be performed by 
POCC personnel. Intermittent monitoring wiE be provided by the Eight crew 
to cover operations during TDRS data gaps. 
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Figure 1-3-15. Spacelab 2 Soft X-Ray Telescope 
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No additional POCC or flight hardware is required for this experiment in any 
of the cases. However, additional software would be required for the POCC 
only to provide for control of the IPS. 

Utilization of the flight crew is nearly the same for all cases, being only 
slightly less in Case 1, because all functions are accomplished by ground 
control. However, because set up time is only a few minutes and monitor- 
ing of housekeeping data is only intermittent, the overall utilization in each 
case is low. 

Ground personnel required to support the experiment are the same, except 
in Case 2 where no pointing engineer is required. 

3. 1. 2. 4 Lyman- Alpha White -Light Coronagraph 

The purpose of this experiment is to obtain high- resolution images of the sun 
and to study the solar corona. It is used in combination with other solar 
experiments and consists of two sensors, one which analyzes the sun in the 

O 

Lyman- Alpha (La) wavelength (1216 A) and the other which photographs 
the sun (the white-light coronagraph [wLc] ). Lyman-alpha WLC experiment 
characteristics and operations applicable to this study are: 

• Mounted on IPS, 

• Data is gathered on film (WLC) and a 200 kBFS data train (La). 

• Housekeeping measurements («40) are monitored during operation. 

• Experiment is shut down between runs. 

• No set up is required. After initiation, experiment runs through 
program automatically. 

• Crew involvement is small during data run (monitoring). 

• Some real-time data analysis is required on the La output. 

The operation of this experiment requires, in Case 1, that ground control 
slew the IPS to the sun and activate the sensors. The experiment will run 
through the program automatically without additional commands. The inter- 
faces with the. CDMS are shown in Figure 1-3-16 with the ground commands 
being processed by the appropriate flight computer and routed to the end 
items through a subsystem or experiment RAU. The scientific data from 
the WLC is recorded on film while the data from the La is downlinked on a 



1 .. 


1 

J 


rm 























200 kBPS data train for monitoring and analysis by the PL Housekeeping 
measurements. for both sensors will be telemetered for evaluation by the 
ground personnel. The housekeeping data will also be available for the 
flight crew, in support of ground personnel, to monitor the health and opera- 
tion of the experiment, especially during the TDRS gaps. 

For Case 2, the command and monitoring of the experiment will be accomp- 
lished by the flight crew. This will be performed in the AFD at the DDU/KB 
or at the dedicated experiment C&D panel. Interface with the end items will 
be through appropriate computers and RAUs. The flight crew will monitor the 
health and operation of the experiment using the housekeeping data. However, 
it is necessary to monitor the output of the La sensor to determine the occur- 
rence of solar phenomena which might require additional data runs. The 
continual analysis of the output data, at 200 kBPS, would require a large 
computer capability. This can be accomplished in Case 1 by the ground- 
based computer but would not be within the capability of the flight computer. 
Consequently, it is recommended that a detector be developed and incorpo- 
rated into the La equipment to detect solar phenomena and alert the flight 
Crew of the presence and location of them. The flight crew, in conjunction 
with ground personnel via the voice link, can then determine if additional 
data runs should be conducted. 

In Case 3, it is recommended that the control of the IPS and the experiment 
be maintained by the flight crew and that, as in Case 1, the monitoring and 
evaluation of scientific and housekeeping data be accomplished by the PI in 
the POCC. The addition of the solar detectors will not be required for this 
case. During data acquisition, the flight crew will be required to monitor 
housekeeping data on an intermittent basis especially during TDRS gaps. 

No additional POCC hardware additions are required for any of the three 
cases, and only the addition of the solar detector was identified for Case 2. 
Control of the IPS or experiment will require no new additions to software 
onboard; however, additional software must be provided at the POCC for 
Case 1, for control of the IPS. 

Flight crew utilization is less for Case 1 than Cases 2 or 3 because ground 
personnel are controlling the experiment. However, since set-up time is 



small and only intermittent monitoring is required, the flight crew activities 
are not large in any of the cases. 

Ground support for the experiment is the same for all cases except that no 
pointing engineer is required for Case 2. 

3. 1.2. 5 High-Sensitivity X-Ray Burst Detector 

This experiment is used to investigate x-ray emissions of the sun. It is 
used in combination with other solar experiments. High- sensitivity x-ray 
burst detector experiment characteristics and operations applicable to this 
study are: 

• Mounted on IPS. 

• Data rate of 60 kBPS. 

• Housekeeping measurements («10) are monitored during operation. 

• Experiment is shut down between runs. 

• No set up required. After activation, experiment runs through 
program automatically. 

• Crew involvement is small during data gathering (monitoring). 

• No real-time data analysis. 

In Case 1, the burst detector will be controlled by ground commands, which 
will slew the IPS to the sun and initiate data-taking. The interfaces with the 
CDMS are shown in Figure 1-3-17. The commands will be processed by the 
Spacelab computers and routed to the IPS and experiment through appropriate 
RAUs, Scientific and housekeeping data will be downlinked to the POCC for 
monitoring by the PI to determine proper operation of the experiment. The 
housekeeping data is also available for onboard monitoring by the flight crew, 
especially during TDRS data gaps. 

Flight crew activities, in Case 2, include the control of the IPS and activa- 
tion of the burst detector. The scientific data will be downlinked to the 
ground for analysis later in the mission or after mission completion. No on- 
board analysis is required. During Case 2 operations, the crew will monitor 
the housekeeping measurements to verify experiment operation. Onboard 
control and monitoring will be accomplished at the AFD DDU/KB or the 


MCDOtVMEEt- aaVGLJXS 




55 



































dedicated experiment C&D panel. Interface with, the CDMS, the IPS, and 
experiment will be through the appropriate computer and RAU. 

In Case 3, the control of the IPS and experiment should be maintained by the 
flight crew while monitoring of the scientific and housekeeping data should 
be performed by the PI at the POCC. Intermittent monitoring of the house- 
keeping data will be accomplished by the flight crew, especially during times 
of TDRS data gaps. 

No additional hardware is required at the POCC or onboard to support this 
experiment. However, additional software is required for the POCC only 
to provide for control of the IPS, 

Flight crew utilization is essentially the same for all cases, with only 
slightly less support required in Case 1. Because there is no set up required 
and since monitoring of housekeeping data is intermittent, overall utilization 
in each case is low. Ground personnel support is the same for all cases except 
that no pointing engineer is required for Case 2. 

3. 1. 2. 6 Skylark Cosmic X-Ray Telescope 

This experiment is used to map x-ray sources in space. It is used in com- 
bination with the LLLi TV. Skylark cosmic x-ray telescope experiment 
characteristics and operations applicable to this study are: 

• Mounted on MPM. 

• Data rate is 4 kBPS. 

> Housekeeping measurements («5) are monitored during operation, 

0 Experiment is shut down between runs. 

• No set up required. After activation, experiment runs through 
program automatically. 

• Crew involvement is small during data gathering (monitoring). 

• No real-time data analysis. 

The operation of this experiment, in Case 1, will be by ground commands; 
the MPM will be slewed to the spatial target, and the data run will be 
initiated. The interfaces with the CDMS are shown on Figure 1-3-18. The 
ground commands will be processed by an onboard computer and routed to 
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Figure 1-3-18. Specelab 2 Skylark Cosmic X-Ray Telescope 


























the MPM or experiment through the appropriate RAU. Scientific and house- 
keeping data are transmitted to the ground to be analyzed by the PI at the 
POCC. The housekeeping data is also available for intermittent monitoring 
by the flight crew, especially during TDRS data gaps. 

The operation of the MPM and experiment, in Case 2, will be controlled by 
the flight crew. The MPM will be slewed and data-taking initiated. House- 
keeping measurements are monitored by the flight crew to verify experi- 
ment operation. The control and monitoring will be conducted at the DDU/KB 
or at the dedicated experiment C&D panel, both located in the Grbiter AFD, 

In this case, the scientific data will not be monitored onboard because no 
real-time analysis is required. However, it will be downlinked for sub"e- 
quent analysis. 

In Case 3, the MPM and experiment will be operated by the flight crew, but, 
as in Case 1, the housekeeping and scientific data will be monitored by the 
PI. Flight crew support of the PI can be provided by intermittent monitoring 
of the housekeeping data, especially during times of TDRS data gaps. 

Activities in all cases can be accomplished with no additional hardware. No 
new additional software is required onboard but, additional software is 
required in the POCC for control of the MPM in Case 1. 

Flight crew utilization is low in all cases because activation time is small 
and monitoring is only required intermittently. Flight crew utilization is 
slightly less in Case 1 because the control is maintained in the POCC. 


Ground personnel supporting the experiment would be the same for all three 
cases except that no pointing engineer is required in Case 2. 


3. 1. 2. 7 LLL TV 

This experiment is used in combination with the Skylark cosmic x-ray 
telescope and serves as an aspect camera for that experiment. It is also 
used to detect faint objects in the presence of bright stars. LLLx TV 
experiment characteristics and operations applicable to this study are: 

• Mounted on MPM. 

• Data is video. 
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• Housekeeping measurements («1) are monitored during operation* 

• Experiment is shut down between runs. 

• No set up required* Experiment operated automatically after 
activation, 

• Crew involvement is small during data gathering (motitoring), 

• Real-time visual analysis is required on intermittent basis. 

In Case 1, this experiment will be controlled by ground commands, the MPM 
will be slewed, and the TV camera activated. The interfaces with the CDMS 
are shown in Figure 1-3-19. The ground commands will be processed by the 
onboard computers and routed through appropriate RA Us to the end items 
Housekeeping data will be monitored by the PI. The video signal will be 
monitored also by the PI and will be analyzed by ground computers to identify 
any faint objects. The housekeeping data and the video signal will be moni- 
tored intermittently by the flight crew, especially during TDRS data gaps. 

In Case 2, the MPM and experiment will be controlled and the housekeeping 
data and video will be monitored by the flight crew. The video will be down- 
linked for subsequent analysis. The control and monitoring will be accom- 
plished at the DDU/KB or at the dedicated experiment C&D panel, both located 
in the Orbiter AFD. 

In Case 3, it is recommended that MPM and experiment control be accom- 
plished by the flight crew and that the housekeeping data and video be trans- 
mitted to the ground for monitoring and analysis by the PI. The flight crew 
can provide monitoring support during times of TDRS data gaps. 


The activities of all three cases can be accomplished with no hardware 
changes. The only software changes will require additions to POCC software 
capabilities, in Case 1, to control the MPM. 


Flight crew utilization is slightly less in Case 1 than in Cases 2 or 3, because 
there is little set-up time and monitoring is only intermittent. 

Ground personnel supporting the experiment would be the same in all cases, 
except that no pointing engineer is required for Case 2, 
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3. 1. 2. 8 Far UV Schmidt Camera/Spectrbgraph 

* 

This experiment is used to perform spectrometry and photometry of spatial 
objects. Far UV Schmidt camera/ spectrograph experiment characteristics 
and operations applicable to this study are: 

• Mounted on. MFM. 

• Data is gathered on film. 

• TV camera is part of unit and is used to provide identification of 
what is being observed. 

• Housekeeping measurements (*»4) are monitored during operation. 

• Experiment is shut down between runs. 

• Setup includes programming corrector plates and mirror gratings. 
Experiment runs through program automatically. 

• Crew involvement is required intermittently during data runs to 
monitor experiment and record time and targets. 

• No real-time data analysis. 

In Case 1, the MFM and experiments will be controlled by ground commands. 
In operation, the MPM will ee slewed to the target, the experiment corrector 
plates and gratings will be programmed and data-taking will be initiated. The 
interfaces with the CDMS is shown in Figure 1-3-20. The ground commands 
will be processed by the appropriate Spacelab computer through the RAUs 
and then 1 o the end item. The TV camera in the experiment will provide 
real-time presentation of the target being observed. All scientific data is 
recorded on film contained within the experiment. Housekeeping data will be 
monitored by the FI in the POCC. The flight crew will support experiment 
operations by monitoring the video and housekeeping data on an intermittent 
basis, especially during times of TDRS data gaps. 

In Case 2, the command and monitoring activities will be performed by the 
flight crew, A voice link will provide PI support for the flight crew activities. 
The control will be accomplished at the DDU/KB or at the dedicated experi- 
ment C&D panel, both located at the Orbiter AFD. Interface with the IPS 
and experiment will be through the appropriate computer and RAU. 

Housekeeping data and TV will be intermittently monitored by the flight crew 
to verify the health of the experiment and the target being observed. 
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In Case 3, it is recommended that the control of the MPM and experiment be 
performed by the flight crew while the monitoring of experiment operation 
and TV be accomplished in the POCC by the PI. The flight crew will support 
the ground personnel by monitoring these outputs during TDRS data gaps. 

The activities of all three cases can be accomplished with no hardware 
additions to the POCC or to onboard systems. Control of the MPM will 
require additional software only for the POCC. 

Flight crew utilization is slightly less for Case 1 than the other cases 
because more functions are being performed on the ground; however, in all 
cases the utilisation is low because set-up time is small, a couple of minutes, 
and monitoring is required only intermittently. 

Ground personnel supporting the experiment would be the same for all three 
cases except that no pointing engineer is required for Case 2. 

3. 1. 2. 9 Transition Radiation Spectrometer 

This experiment is used to determine fLux and energy spectra of cosmic 
protons and electrons. Transition radiation spectrometer experiment char- 
acteristics and operations applicable to this study are: 

• Hardmounted on pallet. 

• Data rate is 50 kBPS, 

• No housekeeping data. 

• Unit is operated continuously throughout mission. 

• No set up required; once activated, experiment operates automatically. 

• No crew involvement during data gathering except in Case 2, 

• No real-time data analysis, but identification and location of energy 

sources are desirable. 

The operation of this experiment requires, in Case 1, that the unit be 
activated as early as possible in the launch sequence to commence data -taking. 
The experiment will operate continuously during the mission until deorbit when 
it will be shut down. The interfaces with the CDMS are shown in Figure 1-3-21 
with ground commands being processed by the experiment computer and dis- 
tributed through the appropriate RAU, Scientific data is transmitted at a rate 
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Figure 1-3-21. Spacelab 2 Transition Radiation Spectrometer 
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of 50 kBFS and will be monitored by the FI. Subsequent analysis will be 
performed to evaluate the data. The experiment has no housekeeping data to. 
be monitored. No flight crew support will be required for this experiment. 

For Case 2, the experiment will be activated by the flight crew, either by 
commands generated at the DDU/KB or at the dedicated experiment C&cD 
panel, both located in the Orbiter AFD. This activation will be accomplished 
as early as possible during the launch or orbital phases. The data output of 
the experiment, a 50~kBPS digital stream, cannot be continuously processed 
and analyzed by the onboard computer. In order to increase the scientific 
return of the identification of specific energy sources which might require 
additional data acquisition (Case 2, in particular), it is recommended that a 
detector be developed as an integral part of the experiment. This detector 
will alert the flight crew of the presence and location of unique energy 
sources, and, with the use of the voice link to the PI, permit the crew to 
determine if additional data acquisition is required. 

In Case 3, it is recommended that the control and monitoring of the experiment 
be performed, as in Case 1, by ground personnel. No flight crew support 
will be required. 

The activities of all three cases can be accomplished with no hardware 
additions to the FOCC and only the addition of the detector identified for 
Case 2. Control of the experiment will require no new additions to onboard 
or FOCC soft ,are. 

No utilization of the flight crew is required for Cases 1 and 3. Since there is 
no set-up required and because monitoring is required only intermittently, 
flight crew activities are small for Case 2. Ground support for the experi- 
ment is the same for all cases. 

3. 1. 2. 10 Extreme UV Imaging Telescope 

This experiment is used to obtain extreme UV images of stellar objects. It 
is used in combination with the 65 -cm photo heliograph. Extreme UV imaging 
telescope experiment characteristics and operations applicable to this study 
are: 

• Hardmounted on pallet. 

• Data rate of 200 kBFS. 

r 
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• Housekeeping measurements (»4) are monitored during operation. 

• Experiment is shut down between runs. 

• Set up requires monitoring of hous ekeeping measurements for approx- 
imately one minute after activation. Experiment runs automatically. 

• Crew involvement during data acquisition includes recording of 
Shuttle aspect angles. 

• Some real-time, or near real-time, data analysis is required. 

In Case 1, the extreme UV imaging telescope will be controlled by ground 
commands. The experiment will be activated and housekeeping measurements 
will be monitored. After this initial activity, the experiment will operate 
automatically. The interfaces with the CDMS for this experiment are shown 
in Figure 1-3-22. The ground commands will be processed by the Spacelab 
computers and routed through appropriate RAUs to the unit. Scientific data 
will be downlinked to the POCC and will be evaluated by the PI to determine 
unique sources of extreme UV. Housekeeping measurements will be mon- 
itored to determine proper operation of the experiment. The flight crew will 
support ground operations by recording Shuttle aspect angles and by monitor- 
ing the housekeeping data on an intermittent oasis especially during times of 
TDRS data gaps. 

Flight crew activities in Case 2 will be similar to those performed by the 
ground personnel in Case 1. The experiment will be activated and housekeep- 
ing measurements will be monitored for approximately one minute prior to 
the start of data acquisition. The control of the experiment will be accom- 
plished through the DDU/KB or the dedicated experiment C&D panel located 
in the Orbiter AFD. Housekeeping measurements will be monitored inter- 
mittently and Shuttle aspect angles will be recorded. The scientific data, a 
200 kBPS digital stream, cannot be continually processed and analyzed by the 
onboard computer. In order to increase the scientific return of the experi- 
ment for Case 2, it is recommended that a detector be developed as an 
integral part of the experiment. This detector will alert the flight crew of 
the presence and location of unique extreme UV sources and, with the use of 
the voice link to the PI, permit the crew to determine if additional data runs 
are required. 
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Figure L3-22. Spacelab 2 Extreme UV Imaging Telescope 
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In Case 3, it is recommended that the flight crew control experiment activa- 
tion and the initiation of data acquisition. The scientific and housekeeping 
data should be downlinked to the POCC for PI evaluation, as in Case 1. In 
this case, the addition of the extreme UV detector will not be required. 

During data acquisition, the flight crew will be required to monitor the house- 
keeping data on an intermittent basis, especially during times when there are 
TDRS data gaps. 

The activities of all three cases can be accomplished with no hardware addi- 
tions to the POCC and only the addition of the extreme UV detector identified 
for Case 2. Control of the experiment will require no new additions to soft- 
ware onboard or at the POCC. 

Utilization of the flight crew is slightly less for Case 1 operations because 
the ground personnel control and monitor the experiment. The flight crew is 
required to periodically record Shuttle aspect angles and to monitor the 
housekeeping data, especially during TDRS data gaps. 


Ground support for the experiment is the same for all cases. 


3. 2 INTEGRATED EXPERIMENT ANALYSIS 


Based on NASA MSFC-supplied mission experiment time lines, each of the 
individual experiment operating plans for each of the three study cases 
developed in Task 1 were integrated to identify mission and/or support system 
total demands. Crew demands, including VFI, were assessed along the 
entire time line. Total demands were assessed by reviewing the entire 
time line to select certain critical high-activity periods for more detailed 
assessment. System impacts were identified and integrated mission support 
requirements were established for each study case (e. g. , crew size, POCC 

manning, downlink data rates, uplink command rates, TV transmission, etc. ). 


3. 2. 1 Spacelab 1 Integrated Experiment Analysis 

The operation of the Spacelab 1 experiments in an integrated mode was 
analyzed using a NASA MSFC-supplied detailed mission time line. A 
summary of that time, line, indicating experiment operations only, is shown 
in Figure 1-3-23. While certain Spacelab 1 experiments tend to operate in 
groups (e. g, , night side viewing AP -09, AP-13, and APE -01), in general, 
operations are independent of each other insofar as resource utilization 
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permits. Most external -viewing experiments require earth orientation and 
tend to operate in groups, while most internal laboratory-type experiments 
are generally distributed to preclude excessive resource demands. As 
indicated in Figure 1-3-23, experiment operations are not initiated until 
T+12 hours and terminated around T+154 hours. The summary time line 
indicates periods of experiment activity; however, these are not necessarily 
continuous. APE-01 LIDAR is operating only during night side passes, 
typically for 30 minutes per orbit, followed by a quiescent housekeeping 
period and then recalibration for the next run. Only a few experiments, such 
as SPE-80/85, EO-Ol, or STE-10, may run nearly continuously for several 
hours or more. Even with these experiments, operating demands and 
data production peaks are generally limited to only parts of the cycle. As 
Figure 1-3-23 indicates, seldom are more than two or three experiments 
operating during any one period. One of these periods, which appears to be 
one of the highest activity periods is the first shift (T+12 to T+20) when 
AP-09/13, APE-01, and LS-13 operate. 
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Table 1-3-6 identifies four time periods identified as high-demand periods 
for deeper analysis of support requirements. The detailed time line was 
used to sum the combined demands from each of the individual experiments 
over these periods. 

In the process, these periods cover all experiments except for the two 
camera experiments, EOE-Ol andASE-01. The camera experiments do 
not impose high demands on the CDMS, although they can impose loads on 
the crew during their activation or deactivation. 


As Table 1-3-6 indicates, Spacelab 1 experiment operations place significant 
demands on crew support, even for Case 1 where primary experiment 
monitoring and control is from the POCC. Crew demand is rounded up to 
integral values and does have greater margin for Case 1. Case 2 support is 
based on a degree of increased data monitoring by the CDMS to relieve the 
crew of excessive monitoring demands. Demands on CDMS and POCC are 
all within their capability except for CDMS op e rating memory demands for 
Case 2. POCC channel demands are the minimum acceptable level required 
simultaneously to support the experiments indicated. In practice, an addi- 
tional channel may be desired for monitoring other experiments status and 
housekeeping. 


To support the development of the integrated demands analysis summarized 
in Table 1-3-6, the highest activity period indicated (GET 12-19) was analyzed 
in some detail and is presented in Figures 1-3-24 through 1-3-29. For each 
case, there is an onboard integrated time line and a corresponding POCC 
integrated time line. The experiment profile presented at the top of the 
Figures is the same in each case for convenient reference. >\s discussed 
earlier, experiment operating periods are generally comprised of a series of 
operating runs, preceded by adjustment or calibration operations and 
intervening shutdown or standby modes. YFI activities are also indicated 
during this period since it makes similar demands on the payload crew and/or 
mission specialist as well as the data link. It is assumed to place minimum 
demand on the CDMS (except for CDM-03 which exercises the system) and 
none on the POCC (YFI is handled on the ground by the MCC). It was not 
clear if the YFI ground operations at JSC would consume one of the four 
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Table 1-3-6 

SPACELAB 1 INTEGRATED TIME LINE MAXIMUM DEMAND PERIODS 


GET 



12-19 


36-41 


60-66 


100-105 


Experiments 


AP-09/AP-13 

APE-01 

LS-13 


ST-31 

SPE-01 

STE-10 


SPE-80/85 
APE -07 
LS-3 3 


SPE-80/85 

EO-01 


Cases 

Onboard 

Grew (PS and MS)* 
CD MS 

Data Bus (kBPS) 
HRM (kBPS)* 


3 


' 3 


25 

330* 


80 


30 


10 

140 


14 

290 - 


84 


14 8" 

. 130- 



output channels available to the POCC; however, since it appeared possible to 
accommodate POCC needs with only three channels (Cases 1 or 3), this was 
not pursued further. 

Figure 1-3-24 presents the onboard tlir.fi line for Case 1. As indicated, crew 
operations are primarily limited to activation, operation of some VFI, and 
LS-13 experiments. Some monitoring support is also provided, especially 
during TDRS data link gaps with the POCC, Experiment payloads generally 
control their internal housekeeping functions (and provide display) and some 
also control and display their experiment operations to at least some degree 
of autonomy. The CDMS provides for AP-09 pointing support and LS-13 
operations control (AP-09/ 13 and APE-01 calibration and operations control 
are uplinked from the POCC). 

Onboard crew support is within the provided time line up to T+16 hours when 
only one crewman is on duty - support of APE-01 operations at the same time 
as LS-13 and VFI operations should require more than the single crewman 
indicated, possibly PS-2 duty shift should be extended. 

As discussed earlier, CDMS utilization is moderate for Case 1. Although 
operating memory may approach its limit if all programs for an experiment 
are assumed active whenever the experiment is active, in practice, only 
some or parts of these programs may be required at any given time. 

Multiplexer capacity assumes seven channels active during this period, 
including programmed or commanded data provided from the experiment 
computer link. Experiment information rates (including VFI and record 
dumps) are indicated, although actual data rates on the line will be determined 
by the selected multiplexer clock rate. Data downlink is provided for Mode 2 
operation by the TDRS to accommodate the high-TV demands characteristic 
of Spacelab 1, The channel capacities are more than adequate to handle 
even the maximum rate encountered (328 kBPS) which includes playback by 
the payload recorder and provisions for digital voice tag of LS-13 operations 
data. 
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Figure 1-3-24* Spacelab 1 Onboard Integrated Time Line- Case 1 


Case 1 POCC time line over this period is shown in Figure 1-3-25. This 
indicates a high degree of POCC activity involved in operating and monitoring 
these experiments and is assessed as probably the most active Case 1 
period for POCC for Spacelab 1. POCC personnel requirements are summed 
at 20 active positions (including a Case 1 basic core of 10) up to T-fT6. This 
also requires up to eight experiment-dedicated CRTs (above the basic core 
and STS displays) as well as use of the two command panels and a pointing 
command panel for the POCC control of EEL TV (AP-13) operations in 
conjunction with AP-09. POCC computing support requirements are indicated 
only by general functions in this section. They are quantified (in terms of 
additional programs and instructions to the basic host-provided capability) 
in Subsection 3.4.2. 

Figure 1-3-26 presents the onboard time line for Case 2 over the same time 
period. Additional onboard demands on operations (AP-09/13 and APE-13) 
and monitoring raise crew support needs (including VFI) up to three during 
the first hour and require maintaining a two -man shift requirement into the 
next shift. This assumes only minimal monitoring demands on the crew, 
using automated CDMS programs to monitor data. The resultant work load 
on the experiment computer may exceed its current memory capacity. 
However, the data available and the level of analysis could not verify this. 
Estimates of program sizes, based on parameters or bits operated on for 
each function, at tliis point are debatable and closer editing- may reduce the 
scaling factors used. In addition, programs may be segmented and pulled 
out from mass memory only during immediate use, reducing the storage 
demands on the operating memory. At any rate, the overload (factor of 2) 
was not sufficient at this time to assess that additional computer capacity 
was required for Case 2, automated monitoring. Case 2 requires increased 
use of DDU/KB units (still within capacity). Multiplexer use is essentially 
the same in all cases, the difference is how the downlink is used on the 
ground. However, TV downlink is limited to those portions of AP-13/AP-09 
vital to postflight analysis. No LS-13 TV is provided since POCC has no 
TV display, by definition. VFI TV downlink (HAB-01) is assumed available 
to the- MGG; 
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Case 2 POCC requirements are minimal over any time period. Figure 1-3-27 
indicates four to six additional specific experiment personnel are required 
over a basic POCC core of eight. No equipment, except voice link, is 
required. 

Case 3 onboard time line CDMS utilization is very similar to Case 1 
(Figure 1-3-28). Crew support requirements are closer to Case 2, three 
men initially and a two -man crew on the next shift. If need be, this might 
be reduced to nearer the Case 1 level by restoring AP-13 operations and 
control to the POCC. (This reflects the flexibility in use of resources 
available to Case 3 compared to Cases 1 or 2, ) For this study, it was 
decided to retain onboard control so long as crew size could be reasonably 
accommodated and no extensive software and CDMS requirements were 
generated (as in Case 2). Again, the multiplexer time line is the same. 

TV downlink is the same as for Case 1. 

POCC requirements for Case 3 (Figure 1-3-29) are closer to Case 1, Per- 
sonnel requirements are less (16 versus 20 up to T+16 hours); however, 
display needs are essentially the same (eight experiment-dedicated CRTs), 
but still well within the baseline POCC configuration. No command functions 
or panels are indicated, but backup or selected use to minimize crew peak 
work loads might be considered in later planning. 

In the assessment of the Spacelab 1 experiments, a concern for the acquisition 
of the highest quality of scientific data identified the need for additional 
monitoring capability for Case 2. In Cases 1 and 3, the scientific data is 
available in the POCC for computer and PI analysis. However, during 
Case 2, this data link is not available. In addition, even with maximum 
payload crew (five including mission specialist), only limited monitoring 
time was available compared to that provided by a ground facility and team. 
The approach used for Spacelab 1 was to sample the experiment scientific 
data for preprogrammed logic and limit checks by the experiment computer. 
This approach was selected because most of the experiments already 
interfaced with the CDMS to some degree, and many of the experiments were 
subjet t to a variety of test conditions including changes during the mission. 
This would allow changing and updating the value of monitor program 
parameters depending on the specific experiment test conditions. Except 
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Figure 1-3-27. Spacelab 1 Ground POCC Integrated Time Line — Case 2 
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Figure 1-3-28. Sjiacetab 1 Onboard Integrated Time Line — Case 3 
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for AP-09, AP-13, or ST-31, no image data is involved (hard-copy film 
data is restricted to postflight analysis in all cases). For these three 
experiments, onboard crew monitoring of image data, coupled with voice 
link to the appropriate POCC PI, is used. For other experiments and non- 
image data from AP-09, and ST -31, software programs are provided to 
assess whether data is being produced or acquired when expected and if it 
falls within expected ranges of values. Variations or excursions are called 
to the attention of the crew for assessment. The quality of this assessment, 
from the limitation of the automated check, and the limitation of crew skills 
and work load, would often tend to be less than provided in Cases 1 or 3 
where a dozen or more qualified specialists can monitor the data at the POCC, 
Table 1-3-7 presents an assessment of relative scientific data quality which 
might be expected in each case, using Case 1 as the nominal reference case. 
Depending upon their operating and data characteristics, some experiment's 
quality are more subject to degradation than others. For example, for 
AP-09 and AP-13, understanding of complex and subtle visual data which 
cannot be easily verbalized to the ground (POCC PI) would tend to limit 
these experiments to the onboard crew's skill and understanding. On the 
other hand, SPE-01 data can largely be easily described and quantified by 
the crew over the voice loop, allowing better interpretation of results and 
uplink of advice by the POCC PI. An average value is shown as a general 
indicator; however, since not all experiments produce data of equal value, 
the average value should not be assessed as a measure of the relative 
scientific value in each case. Similarly, the assessment inherently assumes 
a relative crew skill and PI skill and an experiment adaptation potential 
(capability and requirement) to mission updating. 

The following general findings were derived in the Spacelab 1 payload 
evaluations with the degree of applications varying with payload. 

3.2.1 .1 Case 1 

A. Control functions and operations management are centralized in 
POCC. POCC controls onboard automation. 
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Table 1-3-7 

SPACELAB 1 - RELATIVE SCIENCE QUALITY ASSESSMENT 





Case 1 
(Reference) 

Case 2 

Case 3 

1. 

AP-09 

Electron Accelerator 

1.0 

0. 5 

1,0 

2. 

AP-13 

LLL TV 

1. 0 

0. 5 

1. o 

3. 

ST-31 

Drop Dynamics 

1. o 

0.7 

0. 9 

4. 

EO-01 

Cloud Physics Lab 

1.0 

0. 7 

1.0 

5. 

LS-13 

Minilab 

1. 0 

0. 8 

1. 0 

6. 

APE -01 

LIDAR 

1.0 

0. 6 

0.9 

7. 

SPE 80/85 

Space Processing 

1. o 

0. 6 

1,0 

8. 

SPE-01 

Electrophoresis 

1. 0 

0. 8 

1.0 

9, 

EOE-01 

Metric Camera 

1.0 

1.0 

1.0 

10. 

APE -07 

IR Radiometer 

1.0 

0. 7 

1. 0 

11. 

STE-10 

Heat Pipe 

1.0 

1. 0 

1.0 

!2. 

ASE-01 

Wide-Field Galactic Camera 

1. 0 

0.9 

1.0 



Average 

1.0 

0.73 

0.98 


B. Flight crew plays role of support technician (activates manual tasks). 

C. Flight crew workloads are at minimum (of three cases), 

D. POCC equipment and manpower is at maximum. 

E. Case 1 requires that rigid design criteria be imposed early in payload 
development to provide suitable instrumentation and remote control. 

F. Certain kinds of payloads and func tions cannot fit Case 1 in a practical 
way (e. g. a life sciences biomedical specimen extraction and 
processing; manual set ups or servicing). 

G. POCC evaluates malfunctions and problems and develops contingency 
plans with Mission Operations Control Room (MO CR). 

H. Minimum demand is placed on onboard automatic system since 
POCC computation and data monitoring capability is used. 

I. LOS constraint on POCC control must be accommodated in flight 
planning. This is difficult for certain experiments requiring close 
control and having typical runtimes over 1.3 hours.: 
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/ 

3. 2. 1. 2 Case 2 

A. Control functions, monitoring, and operations management are “ i 

centralized onboard, 

B. Flight crew performs technician role plus a more active scientific 
role {highest skill level). 

C. Flight crew workloads are at maximum. 

D. FOCC acts as scientific and engineering advisor, based on verbal 

data received from crew. ^ 

E. POCC assists in evaluating malfunctions and problems and in 

developing contingency plans. j 

F. Maximum demand is placed on onboard data management systems '] ! 

(experiment computer). ; i ; 

G. Case 2 requires design for equipment and flight crew self-sufficiency. 

H. Less sensitive to LOS. i j 

3. 2. 1, 3 Case 3 ) 

A. Control functions and operations are concentrated onboard. 

Monitoring, assessment, planning, and advisory functions are provided 7 \ 
by FOCC. ! : 

B. Tradeoffs are possible to optimize planned operations as hardware — . ! 

and operations mature. 

C. Flexibility exists to react to contingency requirements. i 

D. Intermediate demand is placed on onboard automatic system and on j ! ■ 

flight crew {intermediate skill level), 

■ • . . r ' i ■ 

E. Most payloads which are automated through the CDMS are readily j | 

adaptable, via software changes, to control from either onboard j 

or FOCC, | i 

3. 2. 1, 4 General ~ \. 

A. Except for some real-time TV used only in Cases 1 and 3 and some . . 

ST-31 detain Case 1, essentially the same data stream is downlinked 
in all three cases. The difference is only that for Cases 1 and 3, it is 
processed for real-time display and use. It is downlinked for 
postflight analysis in all cases. 


B. Grew work load is extensive and demanding (multiskill, etc. ) in all 
cases, ; 



3. 2, 2 Integrated Experiment Analysis - Spacelab 2 

The operation of the Spacelab 2 experiments in an integrated mode was 
analyzed using a NASA MSFC-supplied mission time line. The costs related 
to onboard versus ground real-time mission operations required that the 
following details be identified for each of the three study cases: 

A. Flight crew activities and man-loading. 

B. Onboard hardware modifications, 

C. Onboard software modifications* 

D. Ground support activities and man -loading. 

E. Ground hardware modifications. 

F. Ground software modifications. 

This subsection presents the information assessed and the results used in 
analyzing the cost differentials between the three study cases for Spacelab 
Mission 2. 

3. 2, 2, 1 Integrated Mission Activities 

The Spacelab 2 experiments operate in groups depending on the discipline 
from which they were selected. Solar monitoring experiments are active 
concurrently in joint operating programs during daylight portions of the orbit 
while stellar experiments are scheduled during the night portion. This 
results- in. a mission time line, that exhibits a repetitious nature with experiment 
groups being active as the Orbiter revolves through day and night portions 
of the orbit. 

The NASA MSFC -.supplied mission time line was reviewed to determine times 
of maximum experiment activity or unique experiment combinations. Two 
representative time spans. Figures 1-3-30 and 1-3-31 were selected to be 
used in the study analysis. In these figures and in subsequent subsections, 
the experiments and combinations of experiment are identified by abbreviations, 
A listing of these abbreviations is provided in Table 1-3 -S. 

3. 2. 2. 2 Flight Crew and Ground Crew Activities and Man-Loading 

The experiment operations (See Subsection 3. 1) do not require full flight 

crew attention except during that portion of the time line when experiments 
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Figure 1-3-30. Spacelab 2 Experiment Operations (GET 69:00 Hr to 72:00 Hr) 











Table 1-3-8 

SPACELAB 2 EXPERIMENT IDENTIFICATION 


Abbreviation 

Experiments 

TRS 

Transition Radiation Spectrometer 

SC PRO (Sun-Centered Synoptic 
Program) 

65 -cm photoheliograph 

Solar monitor package 

Soft x-ray telescope 

Lyman -Alpha white -light coronagraph 

High- sensitivity x-ray burst detector 

SKY TV 

Skylark cosmic x-ray telescope 
LLL TV 

IPS SLEW 

Slewing of instrument pointing system 

EUV/PH 

Extreme UV imaging telescope 
65 -cm photoheliograph 

Photo 

(Photoheliograph Program) 

6 5 -cm photoheliograph 
Solar monitor package 
Soft x-ray telescope 
High-sensitivity x-ray burst detector 

MPM SLEW 

Slewing of MPM 

SCAM 

Far IJV Schmidt camera/spectrograph 

SC SYN (Sun- Centered 
Synoptic Program) 

65-cm photoheliograph 
Solar monitor package 
Soft x-ray telescope 

Lyman -Alpha white -light coronagraph 
High- sensitivity x-ray burst detector 


are being turned on or off- Monitoring of the experiment at other times is 
required only intermittently. Consequently, the overall flight crew utilization 
for each experiment is low. 


In Case 1, with the control: and monitoring of all experiments being accom- * 
plished by ground personnel, the flight crew is responsible primarily for 
advising, via the voice link, the ground of the status of the experiment and 
monitoring housekeeping data during TDRS datd gaps, in Case 2 , the flight 
crew activities are a maximum because they are required to turn on and off 
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each experiment prior to and after each data run. Even this activity can be 
minimized by controlling each experiment through the computer DDU/KB. 
Experiments can be set up for a run while the required pointing maneuvers 
(Orbiter, IPS, or MPM) are being accomplished and can be activated, as 
required, through the computer interface. Monitoring of the experiments 
will require slightly more crew time than in Case 1, but, here again, the 
computer can be used to automatically perform limit checks on the house** 
keeping data and the crew can concentrate on the monitoring of scientific data. 

Case 3 presents a crew activity between Cases 1 and 2 because the respon- 
sibility for monitoring data is shifted to the ground except during periods of 
TDRS data gaps which average 15 percent of the orbit. 

The combining of individual experiments into the mission time line does not 
require serial addition of crew activities. Set ups and activations can be 
accomplished in parallel and more than one experiment can be monitored 
simultaneously. 

The requirements for the ground crew are inverse to those of the flight crew. 
Little ground support can be provided in Case 2 because only a voice link is 
provided to the POCC. Here, it was determined that only a PI or his assigned 
representative need to be assigned to support experiment activities, 

hi Cases 1 and 3, where monitoring of scientific and housekeeping data can 
be accomplished in the POCC, the ground support necessary was determined 
by evaluating the type and quantity of data downlinked and the complexity of 
the experiment. Relatively simple experiments with little data such as the soft 
x-ray telescope which records data on film, would not require additional 
personnel for this case. Also considered in ground crew man-loading for 
Case 1, was the complexity of set up and activation of each experiment. 

More complex experiments, such as the solar monitor package with three 
active sensors, were assigned additional support. 

The man-loading of the flight crew and ground personnel for each of the cases 
is assessed in Subsection 3, 3. 



3. 2, 2. 3 Onboard Hardware and Software 

The control and display of the experiments is accomplished through the CDMS 
with commands generated by the ground or on-orbit through the DDU/KB or 
the individual experiment C&D panels. 

The small quantity of commands necessary to set up each experiment (i. e. , 
filters and gratings) and initiate data acquisition is well within the capability 
of the CDMS. Control. of the experiment sequences is accomplished within 
the experiment. Data produced by the experiments is transmitted through the 
computer or the HR.M and does not, for Spacelab 2, exceed the capabilities 
of the onboard system. Data profiles for the two representative time spans 
are shown in Figure 1-3-32 and 1-3-33. On Spacelab 2, the VFI hardware 
generates continuous data at a 60 kBFS rate,. Since this data is routed to the 
HRM for transmission to the ground, it is included in these figures so asi to 
identify the total data profile. 

In the assessment of the Spacelab 2 experiments, a concern for the acquisition 
of the highest quality of scientific data Identified the need for additional 
experiment hardware for Case 2. In Cases 1 and 3, the scientific data is 
available in the POCC for computer and PI analysis. However, during Case 2, 
this data link is not available. Although the onboard computer could probably 
be utilized to continusously monitor and process the scientific data of an 
individual experiment, it would seriously limit the system from performing 
other functions. Consequently, the inability to monitor this data and identify 
unique sources of solar or stellar phenomena would degrade the scientific 
data of selected experiments. An assessment of relative scientific data of 
Spacelab 2 experiments for each experiment is shown in Table 1-3-9. 

In order to increase the scientific quality of Case 2, it is proposed that 
selected experiments incorporate detectors that will alert the flight crew to 
the existence of specific phenomena. This can be analyzed by the flight crew, 
and, by coordination with the PI via the voice link, the scheduling of additional 
data runs can be proposed to conduct additional investigation of the phenomena. 
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Figure i-3-32. Spacelab 2 Data Profile {GET 69:00 Hr to 72:00 Hr) 
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Table 1-3-9 

RELATIVE SCIENTIFIC QUALITY ASSESSMENT 



1 

(Reference) 

Cases 

2 

3 

65 -cm Photoheliograph 

1.0 

1.0 

1 . 0 

Solar Monitor Package 

1 , 0 

0, 8 

1 . 0 

Soft X-Ray Telescope 

1.0 

1.0 

1 . 0 

Lyman-Alpha White -Light 
Co ronagraph 

1.0 

0.7 

1.0 

High-Sensitivity X-Ray 
Burst Detector 

1.0 

0.9 

1.0 

Skylark Cosmic X-Ray Telescope 

1.0 

0. 8 

1.0 

Low-Light-Level TV 

1.0 

6.7 

1.0 

Far UV Schmidt 
Gamer/ Spectrograph 

1,0 

1 . 0 

1.0 

Transition Radiation 




Spectrometer 

1 . 0 

0. 6 

1 . 0 

Extreme UV Imaging Telescope 

1.0 

0. 8 

1.0 


The analysis performed for each experiment, to determine if that experiment 
is a candidate for the incorporation of an additional detector, is provided in 
Subsection 3.4. 1. 


3. 2. 2, 4 Ground Hardware and Software 

The requirements for POCC control consoles, displays, and computing 
facilities were compared to the baseline PGCC definition. The Spacelab 2 
data profile does not exceed the computing capabilities in the POCC and will 
require no additional computer facilities. The use of control consoles can 
be assigned to Pis when individual experiments are scheduled in the time line 
The quantity shown in the baseline is sufficient to support the activities of 
Spacelab 2. 

It was assumed that the control of the pointing systems (IPS and MPM) is not 
within the baseline software design. Therefore, for Case 1, additional 
software must be developed to provide the necessary commands. This 
analysis is provided in Subsection 3. 4. 2. 
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3. 2, 2, 5 Conclusions 

The assessments of the impacts of Spacelab 2 on ground and flight personnel, 
equipment, and software for the three study cases is developed in Subsections 
3. 3 and 3,4. It is shown that Case 1, providing for ground control and 
display, requires that ground costs escalate to support this effort and the 
flight crew performs minimum activities. In Case 2, the flight crew is 
responsible for controlling and monitoring the experiment operations and 
the ground personnel serve only a support role using the voice link. In this 
case, costly experiment modifications are required to provide for detection 
of solar or stellar phenomena that, in Case 1, could be detected by POCC 
equipment and personnel. 

In Case 3, optimum utilization of both the flight crew and ground support is 
obtained. The flight crew provides control and activation of the experiments 
and the ground monitors and analyzes experiment data. The voice link is 
used in coordinating operational information and for optimizing experiment 
activities. 

3. 3 MISSION OPERATIONS 

3. 3. 1 POCC Operations 

- . ■ * 

3. 3. 1. 1 POCC Summary 

Spacelab 1 and Spacelab 2 POCC Man-Hours 

The POCC related costs are expressed in man-hours for each of the three 
cases for both the Spacelab 1 and Spacelab 2 missions. These costs include 
both experiment and integration personnel required to develop requirements 
and procedures for the POCC as well as the training and staffing of the POCC 
for real-time support of the mission. These hours are shown in Table 1-3-10 
Additional discussion of this table for case comparisons are in subsequent 
paragraphs under Spacelab 1 and Spacelab 2. 

The bottom line of Table 1-3-10 indicates that the grand total POCC-related 
effort is greater for Spacelab 2 than for Spacelab 1. This condition is caused 
by the longer duration of the Spacelab 2 mission (12 days versus 7 days) and 
also by the longer operation durations of the experiments (1,091 hours versus 



Table 1-3-10 

POCC RELATED OPERATIONS - TOTAL MAN-HOURS 




Spacelab 1 


Spacelab 2 


Case 1 

Cas e 2 

Case 3 

Case I 

Case 2 

Case 3 

Experiment OPS (Pis) 







Requirements 

745 

267 

382 

693 

334 

536 

Procedures 

3, 975 

1,416 

2, 035 

2, 770 

1,284 

2,096 

Training 

1,245 

387 

579 

1,111 

408 

798 

POCC Staffing 

933 

572 

637 

2, 620 

1, 707 

2, 180 

(No. of Personnel) 

(38) 

(23) 

(26) 

(32) 

(20) 

(26) 

Total 

6,898 

2, 642 

3, 633 

7,194 

3,733 

5,610 


Payload Integration (MSEC) 


Requirements 

265 

185 

200 

221 

144 

182 

Procedures 

1, 594 

1,114 

1,198 

1, 326 

872 

1,094 

Training 

575 

345 

380 

477 

264 

325 

POCC Staffing . 
(No. of Personnel) 

1, 552 
(20) 

1,162 

(14) 

1,162 

(14) 

2, 680 
(20) 

2,304 

(14) 

2,392 

(16) 

Total 

3,986 

2, 776 

2,940 

4, 704 

3,584 

3,993 

Grand Total 

10,884 

5,418 

6, 573 

11, 898 

7,317 

9,603 


196 hours). The experiment durations for Spacelab 2 cause every experi- 
ment to require two-shift operations, thus, considerably increasing the total 
man-hours, Other factors which influence the man-hour requirements are 
shown in Figure 1-3-34, 

The experiment portion of the Spacelab 1 total man-hours is similar to that 
of Spacelab 2; however, the POGC staffing man-hours are considerably 
greater for Spacelab 2 due to the greater total length of mission and to the 
longer durations of experiments even though the average crew size is 
smaller. Generally, the effort required for development of requirements 
and procedures are greater for Spacelab 1 because of the higher complexity 
and less repetition during the mission. 

The integration portion of the total effort follows essentially the same pat- 
tern with the length of mission causing the greatest difference between 
Spacelab 1 and Spacelab 2, Staffing is generally over 1, 000 man-hours 
greater for Spacelab 2 in each of the three cases. 
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Figure 1-3-34, Manpower Influence Factors 
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PQGC Integration Functions 

Management — Two persons are required for each of the three cases for 
management, one person manages the POCC personnel activities and the 
second has overall experiment responsibility. These functions are required 
full time for all three cases. 



The first function is performed by someone who repeatedly is in charge of 
the POCC and crew activities during mission activities and does not neces- 
sarily follow the payload development cycles. The second function is per- 
formed by the payload manager, and his assistant on second shift, who have 
historical knowledge of the development of all the experiments and their four 
levels of integration. He is the only POCC member that has overall knowl- 
edge of all experiments and the Spacelab systems. 

Payload Operations — Personnel are required for payload operations functions 
to perform coordination between the experiment members of the POCC and 
between them and outside functional areas such as MCC, NASCOM, and 
MSFC, Outside coordination includes coordination between the experiment 
operators in the POCC with the STS and Spacelab systems engineers for 
evaluation and operation of the payload support systems and with the GSFC 
network for data flow, These ac'ivities do not change in degree from one 
case to another. Personnel required in this group are a Spacelab systems 
engineer and a pointing systems engineer. The pointing system engineer is 
only required during mission activities that utilize IPS or payload-provided 
pointing systems. Data management coordination is required to determine 
the payload data requirements on the STS and TDRSS/STDN. Due to the 
reduced POCC data requirements in Case 2, the data management function 
is reduced for that case and somewhat for Case 3. 


Planning — The payload activity planning function is required for (1) replan- 
ning the remaining activities when changes are necessary, (2) coordination 
of activity planning in the POCC and with MCC, (3) formatting uplink text 
for the MS data file, (4) keeping a history of the flight, and (5) responding 
to planning support data requests. These functions are required on each 
shift for all three cases. 



POCC Integration Man- Loading 

The quantity of personnel that are required for each job function as described 
in the previous paragraph is shown in Table 1-3-11, Two equal shifts are 
required throughout the mission duration. These crew sizes were used to 
define the detailed integration man-hours which are described in subsequent 
paragraphs under Spacelab 1 and Spacelab 2. 

The man-loading was developed assuming that the training, procedure 
development, and the learning curves for the Spacelab activities were in an 
operational mode. The level of ground crew activity in the POCC for 
Spacelab 1 and Spacelab 2 is not necessarily representative of future flights. 
The POCC experiment activity does not include the effort required for the 
verification flight test activities. The verification flight test activity does, 
however, impose accommodation requirements on the STS, Spacelab sys- 
tems, and crew, detracting from experiment operations, 

After performing this analysis, it became obvious that the POCC integration 
effort is nearly the same for all three cases. The effort associated with 
these job functions is not appreciably affected by the data that are being dis- 
played in the POCC. Since the integration job functions are primarily 
required for coordination between the payload community and other organi- 
zational areas, they are required for all three cases. Also, since Spacelab 
systems data is being displayed in the MCC Spacelab support room and the 
experiment data interfaces are essentially the same for all three cases, the 
coordination activity tends to remain constant across the cases. 

POCC Experiment Team Functi ons 

A POCC experiment team is required for each experiment that will be oper- 
ated during the mission. The team will be required to be on- station at all 
times that their experiment is in operation. The size of the team varies 
from one to three in accordance to the complexity of the operation and to the 
technical complexity of the experiment. The team consists of the PI with one 
or two other experiment specialists who monitor and evaluate real-time 
experiment housekeeping and scientific data. Two shifts are required if the 
timing causes personnel to be on-station more than 14 hours (maximum) at 
one time. For most experiments, the team is the largest for Case 1 and the 
smallest for Case 2, 
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Table 1-3-11 

POCC INTEGRATION MAN -LOADING 



1 

Case 

2 

3 

Management 

: 2 ■ 

. 2 

2 

Payload Operations 

3 

2 

2 

Planning 

4 

3 

3 

Subtotal 

9 

7 

7 

Pointing Support (Optional) 

1 

1 

1 

Total (Including Option) 

10 

8 

8 


The POCC experiment team is responsible to check the real-time data against 
the predicted data to (1) verify that conditions in the Spacelab are not adversely 
affecting the scientific data quality; (2) verify that the experiment instrumen- 
tation is remaining in calibration and that it is working within limits; and 
(3) constantly evaluate the data to verify that the data is real (distinguish 
between actual and similar data), verify that the data is within predicted 
boundaries, identify phenomenon and/or targets that were not anticipated, 
and identify data that would necessitate changes in the remainder of the flight. 

Detailed experiment team man-loading is presented in subsequent subsections 
under Spacelab 1 and Spacelab 2. 

POCC Operations Analysis Methodology 

Experiments — The number of man-hours estimated to be required for prepa- 
ration of procedures are based on the number of pages that are required for 
the experiment which is a function of the total duration (D) of the experiment, 
its relative technical complexity (C), the repetition (R) of sub tasks during 
the mission, and the number of personnel involved. 


/ 
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The number of man-hours required for preparation of requirements is 
closely related to the number of procedures pages that are necessary to 
fulfill those requirements. Requirement development is also influenced by 
the preceding factors (D, C, and R). 

Training man-hours are a function of the total number of persons involved 
(both shifts) plus the class preparation time and the instructor's teaching 
time, all of which are affected by relative complexity, repetiveness, and 
duration of the experiment. The complexity factors were determined for 
the experiments relative to the various other experiments on Spacelab 1 for 
POCC Case 1. The complexity was then estimated for each experiment for 
the POCC for Cases 2 and 3, relative to Case 1, The higher the complexity, 
the higher the C factor. The same techniques were repeated for Spacelab 2 
experiments and the complexities were determined relative to the complexi- 
ties of Spacelab 1 to provide continuity of analyses for the two missions. 

The repetition (R) factors were determined for experiments relative to the 
other experiments on Spacelab 1. These factors are a function of how much 
of the experiment activity repeats itself during the mission. Since the R 
factor is a multiplier, the more the repetition, the lower the factor. For 
example, if only one procedure is required and it is repeated 10 times during 
the mission, then the repetition factor would be considerably smaller than 
R of an experiment which has no repetition during the mission. The repeti- 
tion factors for Spacelab 2 experiments were determined relative to those or 
Spacelab 1 for purposes of continuity of analysis for the two missions. 

Integration — The methodology for performing operations man-power analysis 
for the Integration effort is essentially the same as for the experiments. 
However, lower factors prevail for technical complexity and repetition, 
as compared to the experiments, because the integration activities are 
closely associated with the Spacelab systems, data systems, and the flight 
crew activities which tend to be similar from one mission to another. Higher 
levels of experience and higher learning curves also reduce the relative 
effort of the integration activity. 



3.3. 1.2 Spacelab 1 Mission 
Spacelab 1 POCC Comparison of Cases 

Experiment — The total Spacelab 1 man-hours required for each case were 
shown in Table 1-3-10, Subsection 3. 3. 1. 1. Table 1-3-10 specifies the 
effort required for requirements, procedures, training, and POCC staffing. 
The total POCC effort was the greatest for Case 1, less for Case 3, and 
least for Case 2. The larger number of POCC personnel involved in Case 1 
is the prime driver that causes all of the -activities' to be higher. The man- 
loading for the Spacelab 1 POCC experiment team is shown in Table 1-3-12. 
The table depicts 8 of the 12 experiment teams as requiring 3 persons for 
Case 1 (an average of 2. 5 persons). Case 2 has seven crews of 2 persons 
and five crews of 1 for an average of 1. 6 persons per team. Case 3 has nine 
crews of 2 persons and three crews of 1 for an average of 1,8 persons 
per crew. 

Summation of personnel listed in Table 1-3-12 adds up to 30 for Case 1, 

19 for Case 2, and 21 for Case 3. Since two shifts per day are required for 
three experiments (AF-13, APE-01, and SPE-80/85), th ; total number of 
persons required at JSC are 38 for Case 1, 23 for Case 2, and 26 for Case 3. 
Additional personnel are required in Cases 1 and 3 to monitor real-time data 
and to perform evaluation of the data providing maximum experiment data 
quality. 

Integration — The effort shown earlier on Table 1-3-10 for POCC payload 
integration indicates that Case 1 is the greatest. Case 3 is less, and Case 2 
is the least. All three cases are closer to each other than those for the 
experiments. As explained in an earlier subsection, the integration effort 
tends to remain relatively constant across the cases since it is a function of 
Spacelab systems and NAS COM data systems which require relatively the 
same effort for all three cases. The basis for this effort for integration was 
the man-loading shown earlier in Table 1-3-11. 



Table 1-3-12 

SPACELAB 1 POCC EXPERIMENT MAN- LOADING 



1 

Case 

2 

3 

1. AP-09 

3 

2 

2 

2. AP-13 © 

3 © 

1 © 

2 © 

3. ST- 31 

3 

2 

2 

4. EO-01 

3 

2 

2 

5. LS-13 

/T\ 

3 

2 

2 

6. APE-01 'o' 

2 

1 

1 

7. SPE- 80/85 o' 

3 

2 

2 

8. SPE- 01 

3 

2 

2 

9. EOE-01 

1 

1 

1 

10, APE- 07 

3 

2 

2 

11. STE-10 

2 

1 

2 

12. ASE-01 

1 

1 

1. 

(T) Two shifts required. 




( 2 ) 2 , 1, and 1 when run 

with AP-09. 




Spacelab 1 POCC Substantiating Data 

Table 1-3-13 displays the next lower level of data that were used to prepare 
Table 1-3-10. It shows the effort required for each experiment for prepara- 
tion of procedures and requirements and for fulfilling the necessary training 
requirements of Spacelab 1. These quantities were derived from factors 
based on experiment duration (D), complexity (C), repetition (R), and 
quantity of personnel involved. 

Man-hours for staffing was based on quantity of personnel and duration of the 
experiments. Preparation time prior to operation and evaluation time during 
postoperation was added to the experiment duration for a more accurate esti- 
mate of staffing for the experiments. This technique was not utilized for the 
integration crew since that crew maintains stations around the clock on a 
two- shift basis and the nature of the work is more routine. 



i. i. 


l ! .= : '• 

U ■ ■ i . >' j 


1 r -1 


2 

s. 






Table 1-3-13 
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SPACELAB 1 POCC RELATED MAN-HOURS FOR EXPERIMENTS 





i 

0 

0 

c 

:* 

iJlN. 

Experiment 

Case 

Crew Size 
1. 2 3 

Experiment 

Duration 

Hour 

Procedures 
~Man- Hours 

1 2 

3 

Requirements 
~ Man-Hours 

12 3 

Training 
~ Man- Hours 

1 2 3 

ft 

1. 

AP-09 

3 

2 

2 

6 . 6 

201 

59 

119 

37 

11 

22 

54 

15 

^0 

I v 

; 2. 

AP-13 

3/3 

1/1 

2/2 

16. 7 

261 

51 

153 

48 

10 

29 

108 

15 

56 


3. 

ST-31 

3 

2 

2 

8. 8 

310 

121 

152 

57 

23 

29 

90 

30 

40 


4. 

EO-01 

3 

2 

2 

19.3 

587 

231 

231 

108 

43 

43 

162 

55 

55 


5. 

LS-13 

'3 

2 

2 

12.2 

296 

145 

204 

55 

28 

39 

84 

35 

50 


6. 

APE- 01 

2/2 

1/! 

1/1 

24. 8 

345 

101 

101 

63 

19 

19 

112 

35 

35 


7. 

SPE-80/85 

3/3 

2/2 

2/2 

56. 4 

785 

308 

540 

144 

58 101 

324 

105 

182 

o 

8. 

SPE-01 

3 

2 

2 

6.2 

243 

120 

120 

45 

23 

23 

72 

30 

30 

-A 

9. 

EOE-01 

1 

1 

1 

5.2 

113 

33 

33 

21 

6 

6 

24 

8 

8 


10. 

APE-07 

3 

2 

2 

15.0 

456 

135 

270 

84 

25 

25 

126 

35 

65 


11. 

STE-10 

: ' 2 

1 

2 

20. 3 

265 

79 

79 

49 

15 

15 

65 

16 

20 


* 

1 i 

ASE-01 

1 

1 

1 

4.3 

113 

33 

33 

21 

6 

6 

24 

8 

8 


Experiment Total 

38 

23 

26 


3, 975 

1,416 

2,035 

745 

267 

382 

1,245 

387 

579 

Integration Total 

10/10 

7/7 

7/7 

166. 0 

1, 594 

1, 114 

1, 198 

265 

185 

200 

575 

345 

380 


\ 


3. 3. 1,3 Spacelab 2 Mission 
Spacelab 2 POCC Comparison >— Cases 

Experiment — The POCC comparison of cases for Spacelab 2 is very similar 
to Spacelab 1. Again, the total POCC effort was the greatest for Case 1, 
less for Case 3, and least for Case 2. These results were primarily influ- 
enced by the number of personnel involved in each case. The three cases 
were relatively closer together on a percentage basis than for Spacelab 1. 

The man-loading for the Spacelab 2 POCC experiment team is shown in 
Table 1-3-14. The average POCC team for each experiment is 1. 6 for 
Case 1, 1, 0 for Case 2, and 1.3 for Case 3. These man-loading levels were 
lower for Spacelab 2 than Spacelab 1 because Spacelab 2 experiments are 
generally less complex and tend to be more self-contained. 

Summation of personnel listed in Table 1-3-14 adds up to 16, 10, and 13 for 
Cases 1, 2, and 3, respectively. Since all experiments require two shifts 
per day, the total number of POCC experiment personnel that are required 
at JSC are 32, 20, and 26 for Gases 1, 2, and 3, respectively. 

Again, the additional personnel are required for Gases 1 and 3 to monitor 
control and evaluate real-time data so that the quality of scientific data is 
at an acceptable lev el. 

Integration — The case-by-case relationship for Spacelab 2 POCC payload 
integration is similar to that of Spacelab 1. Again all three cases are closer 
together than those for the experiments due to consistency of job functions 
in integration. The basis for the integration effort was the man- loading 
shown earlier in Table 1-3-11. 

Spacelab 2 POCC Substantiating Data 

Table 1-3 -15 displays the next lower level of data that wer e used to prepare 
Table 1-3-10. It shows the effort required for each experiment to prepare 
procedures and requirements and to fulfill the necessary training require- 
ments for Spacelab 2. These quantities were derived from factors based on 
experiment duration {D), complexity (C), repetition (R), and quantity of 
personnel involved. 



Table 1-3-14 


SPACELAB 2 POCG EXPERIMENTS MAN- LOADING 


0 © 


0 as 0 



1 

2 

3 

1. Transition Radiation Spectrometer 

1 

1 

i 

2. Far UV Schmidt Camera/Spectrograph 

1 

1 

1 

3. Extreme UV Imaging Telescope 

2 

1 

1 

4. Skylark Cosmic X-Ray Telescope 

2 

1 

1 

5. LLL TV 

2 

1 

2 

6. 65-cm Photoheliograph 

1 

1 

1 

7. Solar Monitor Package 

2 

1 

2 

8. Soft X-Ray Telescope 

.1 

. 1 

1 

9. Lyman- Alpha White- Light Cor onagraph 

2 

1 

2 

10. High- Sensitivity X-Ray Burst Detector 

2 

1 

1 

(T) Pointing required (POCC support is required only for 
Cases 1 and 3 



( 2 ) Two shifts required for all experiments on SL-2. 





Man-hours for staffing was based on quantity of personnel and duration of 
the experiments. Preparation time prior to operation and evaluation time 
during postope ration was added to the experiment duration for a more accu- 
rate estimate of staffing for the experiments. This technique was not 
utilized for the integration crew since that crew maintains stations around 
the clock on a two-shift basis and the nature of the work is more routine. 

3.3.2 Flight Operations 

3 . 3 . 2 . 1 Onboard Summary 

Delta Man-Hours 

The onboard related costs are expressed in delta man-hours. Case 1 is 
defined as the reference base (zero), and the delta man-hours of Cases 2 
and 3 are relative to Case 1. The man-hours shown in Table 1-3-16 are for 
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Table 1-3-15 

SPACELAB 2 FOCC MAN-HOURS FOR EXPERIMENTS 


A- 


X 


2 


Experiment 

Crew Siz 

e 

Experi- 

ment 

Duration 

Procedures 

'"-Man-Hours 


Requirements 

~Man-Hours 

Training 

~Man-Hours 

Case 

i 

2 

3 

Hr 

1 

2 

3 

1 

2 

3 

1 

2 

3 

1. Transition Radiation 
Spectrometer 

i/i 

1/1 

1/1 

279.0 

89 

89 

89 

22 

22 

22 

28 

28 

28 

2. Far UV Schmidt 

Camera/ Spectrograph 1/1 

1/1 

1/1 

12. 5 

48 

24 

48 

12 

6 

12 

21 

10 

21 

3 . Extreme ITV Imaging 
Telescope 

2/2 

1/1 

1/1 

12.4 

60 . 

20 

20 

15 

5 

5 

26 

9 

9 

4, Skylark Cosmic 
X-Ray Telescope 

2/2 

1/1 

1/1 

110. 0 

211 

70 

141 

53 

18 

35 

92 

22 

44 

5. LLLTY 

2/2 

1/1 

2/2 

110. 0 

211 

70 

178 

53 

18 

44 

92 

22 

77 

6. 65-cm Photo- 

heliograph 

1/1 

1 / 1 

1/1 

136. 0 

392 

131 

392 

98 

33 

98 

122 

41 

122 

7- Solar Monitor 
Package 

2/2 

1/1 

2/2 

123 . 6 

791 

396 

593 

198 

99 

149 

346 

124 

260 

8. Soft X-Ray 
Telescope 

1/1 

1/1 

1/1 

123. 6 

316 

158 

158 

79 

40 

40 

99 

50 

50 

9. By man- Alpha White- 
Light Go ronagraph 

2/2 

1/1 

2/2 

47. 2 

302 

151 

302 

76 

38 

76 

132 

47 

132 

10. High-Sensitivity 
X-Ray Burst 
Detector 

2/2 

1/1 

1/1 

13 6. 6 

3 50 

175 

175 

87 

55 

55 

153 

55 

55 

Experiment Total 

16/ 16 

10/10 

13/13 

1,090.9 

2,770 1 

,284 2, 

096 

693 

334 

53 6 

1, 111 

408 

798 

Integration Total 

10/10 

7/7 

8/8 

288. 0 

1, 326 

872 1, 

094 

221 

144 

182 

477 

264 

325 


i ■ 


f n 

- • . i 


i ’ -1 




Table 1-3-16 

ONBOARD RELATED OPERATIONS - DELTA MAN-HOURS 



Case 

Spacelab 1 
1 Case 2 

Case 3 

Spacelab 2 
Case 1 Case 2 

Case 3 

Operations 

Requirements 

Definitions 

0 

160 

60 

0 160 

60 

Crew Activity 

0 

4, 431 

1, 79 1 

0 1,753 

809 

Total 

0 

4, 591 

1, 851 

0 1,913 

869 

Flight Crew Required 
for Experiment 
Operations 

3 

5 

5 

3 3 

3 


(1) the crew activity which, is required to develop requirements and pro- 
cedures for the payload crew and to provide training and for (2) the pre- 
planning activity by MSFC for the definition of requirements for equipment, 
software, and operations support. 

The related onboard delta man-hours for integration of additional onboard 
hardware and software for Cases 2 and 3 have been folded into the respective 
hardware and software costs which are presented in Subsection 3.4 of this 
report. 

The crew activity includes the effort required to develop requirements and 
procedures, to train the crew, and to staff the crew. The delta man-hours 
for Spacelab 1 was considerably higher than for Spacelab 2 as a result of 
additional crewmen being required for Spacelab 1 due to higher technical 
complexity and less repetition of the Spacelab 1 experiments. Spacelab 1 
required three, five, and five crewmen for Cases 1, 2, and 3, respectively. 
While Spacelab 2 required only three crewmen for all three cases. Even 
with additional crewmen on Spacelab 1, the utilization is at a higher level 
than for Spacelab 2. The bulk of the delta man-hours for crew activity is 
for training. 
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The crew activity does not include all of the costs associated with the crew- 
men. In particular, the impact from raising the payload crew from three to 
five was not assessed for the flight crew support. This support includes 

(1) medical (doctors, nurses, technicians, medical equipment, and facilities), 

(2) training equipment (flight simulators, classrooms, training materials, 
on-the-job type training, etc.), and (3) flight support equipment supply and 
control and maintenance (personnel hygiene, waste management, food and 
beverages, wearing apparel, stowage, atmospheric control, etc.). 

The effect of these considerations may range from essentially no effect to 
considerable effect. For example, if the planned medical facility can pro- 
vide support for two additional crewmen without expanding* then the effect is 
minimal. On the other hand, if expansion of the medical facility is necessary, 
then the effect is significant. 

The net effect of these costs, which were not considered, would increase 
Cases 2 and 3 delta costs making them relatively more expensive than 
Case 1. 

The delta integration effort for definition of equipment, software, and sup- 
port requirements is relatively small as compared to the crew related effort. 
A delta of 160 man-hours are estimated for Case 2 and 60 mau-hours for 
Case 3. Since the chosen case will be defined well in advance of the pre- 
planning effort, all of the effort is initial effort and not replanning effort. 

The total number of man-hours for this definition is not significantly 
influenced by a small percentage increase in either onboard hardware or 
software. The only significant increase is for crew support requirements 
definition. 

Payload Crew Functions 

For Case 1, the majority of the crew functions are concerned with house- 
keeping, setups, calibration, pointing, data control, and handling, satisfying 
physical requirements during operation (e. g. , changing film magazines, 
taking blood samples, adjusting equipment, etc. ), deactivating and securing, 
and/or storing equipment and samples. 



In addition to these duties, for Case 2 the crewmen are also responsible 
for performing all experiment operations. This activity includes monitoring 
and controlling experiment data. These data are checked against the pre- 
dicted data to (1) verify that conditions in the Spacelab are not adversely 
affecting the scientific data quality; (2) verify that the experiment instrumen- 
tation is remaining in calibration and that it is working within limits; and 
(3) constantly evaluate the data to verify that the data is real (distinguish 
between actual and similar data), verify that the data is within predicted 
boundaries, identify phenomenon and/or targets that were not anticipated, 
and identify data that would necessitate changes in the remainder of the 
flight. 

In Case 2, items (1) and (2) preceding may be either automated or provided 
by the flight crew to the same level of quality as in Case 1. On the other 
hand, item (3) cannot be automated except to a small degree. Item (3) can- 
not adequately be provided for by the flight crew due to insufficient flight 
crew personnel or due to insufficient knowledge of the experiment. 

Case 2 is not acceptable for a number of experiments of high technical com- 
plexity. For example, Spacelab 1 has several experiments that are judged 
to return scientific results for Case 2 of only about one-half the quality of 
Case 1, 

Crew activities for Case 3 fall between those of Case 1 and Case 2. For 
those experiments that either do not require real-time evaluation or have a 
low technical complexity, they may be either automated or operated by the 
crew (if personnel are available). On the other hand, the remaining experi- 
ments are monitored on the ground to attain the necessary level of experi- 
ment quality. 

Payload Crew Utilization 

For the purpose of this study, the payload crew is defined as the PSs and the 
MS. The commander and pilot involvement was held to a minimum, using 
them only where absolutely necessary. The MS has the primary responsi- 
bility for control and monitor of the VFT and for instrument pointing. The 
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PSs have the primary responsibility for the experiment functions, 
which do not have a MS available, the PS also assumes his duties. 

Crew real-time effort was estimated for each experiment and for each opera- 
tion required for VFT. The individual experiment man-loading levels were 
analyzed on an integrated basis to determine the quantity of man-hours 
required for every hour of the mission for Spacelab 1 and Spacelab 2, 

Assuming 100% utilization of the crewmen while they are on-station, the 
quantities of crewmen were determined as listed previously on Table 1-3-16. 

The flight payload crew lev el- of- effort is considered the norm for Case 1 
for which the delta man-hours are zero. Cases 2 and 3 flight man-hour 
deltas are determined in relationship to Case 1. 

Cases 2 and 3 payload activities should be reshaped in accordance to their 
ground rules to increase the effective utilization of the crew for those cases. 

For analysis purposes, the flight crews were assumed to never be sick 
during the mission. Also, a backup crew was not considered for determin- 
ing man-hours. 

Onboard Operations Analysis Methodology 

The methodology utilized for onboard- related man-hour estimates was very 
similar to that used for POCC -related estimates (reference Subsection 3, 3, 1,1 
POCC Operations Analysis Methodology) for the experiments. Similar 
techniques were used to determine the man-hours needed for preparation of 
crew requirements and procedures as well as for crew training. 

Factors for duration (D), technical complexity (C), and repetition (R) were 
also used. The complexity factors were first estimated for the flight crew 
activities for each experiment in Case 2 since that is the most complex case 
for the flight crew. These were the same complexity factors as those used 
for the POCC, Case 1. Complexities of the flight crew activities for Cases 1 
and 3 were determined relative to Case 2 (flight). 



The repetition factors utilized for flight operations analyses were identical 
to those used in the POGC operations analyses since repetition of the experi- 
ments is not dependent upon relative flight or ground activities. 


3. 3. 2, 2 Spacelab 1 Mission 


Spaeelab 1 Onboard Comparison of Cases 

The crew activity delta man-hours for each case was shown in Table 1-3-16, 
The most significant components of crew activity are development of crew 
requirements and procedures and especially crew training. The case 
relationships are exemplified by ratios of these effort? of Cases 2 and 3 to 
Case 1. The ratios to Case 1 for requirements development are 1.9 for 
Case 2 and 1. 5 for Case 3. The ratios are the same for procedures 
development. The ratios to Case 1 for training are 4. 5 for Case 2 and 2.2 
for Case 3. The greater crew involvement (larger number of crewmen) in 
Cases 2 and 3 is the prime driver that causes the ratio to be higher (greatest 
in Case 2 and least for Case 1). 

The ability to monitor and control payloads from the ground (Case 1) provides 
a significant degree of flexibility not available in Case 2. Should onboard 
problems (e. g. , crew sickness or diversion of attenti'ur from one payload to 
problem investigation of another payload or STS support system) preclude 
accomplishment of scheduled payload activities, ground control could be 
assumed with a potential of salvaging significant payload data. 


Table 1-3-17 shows the man-loading required for the twelve experiments 
aboard Spacelab 1. This table was used in conjunction with the Strawman 
time line to integrate the real-time man-loading requirements throughout the 
flight. Each hour was assessed to determine the total quantity of crewmen 
required to perform all crew functions. The results indicate that three, 
five, and five crewmen are required for Cases 1, 2, and 3, respectively. 

The Case 1 crew activity requirement for three men was in agreement with 
the Strawman document^. However, the schedule and the quantity of experi- 
ments cause the utilization of only three crewmen to be very high. 


Spacelab 1, Strawman, MSEC, SE-012-020-2S, October 1976. 
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Table 1-3-17 _ 

SPACELAB 1 FLIGHT PAYLOAD CREWMEN UTILIZATION^ 


Case 




1 

2 

3 

1 . 

AP-09 

0.2 

0.9 

0.8 

2. 

AP-13 

0.2 

0.9 

0. 8 

3. 

ST-31 

0.4 

1.0 

0.6 

4. 

EO-01 

0.4 

0. 7 

0.7 

5. 

LS-13 

1,3 

1.3 

1.3 

6. 

APE-01 

0.4 

1.2 

1.2 

7. 

SPE-80/85 

0.3 

0.7 

0.4 

8. 

SPE-01 

0. 5 

0.8 

0.8 

, 9 ' 

EOE-01 

0 . 1 

0. 5 

0.5 

10. 

APE-07 

0.2 

0.4 

0.4 

11. 

STE-10 

0.1 

0.5 

0. 5 

12. 

ASE-01 

0.3 

0.5 

0. 5 


Values are crewmen required (I. 0 equals one man) during 
operation (higher during activation, deactivation, etc. ). 



Consideration should be given to reducing the number of experiments on 
Spacelab 1 to help alleviate that problem. 

Case 2 showed an increase of crewmen to five due to the greater involvement 
of the crew with the experiments. Even with five crewmen aboard (two on 
one shift and three on the other), the utilization was unreasonably high to the 
point that scientific requirement fulfillment was questionable. 

It is not possible to get the same experiment scientific return in Case 2 as it 
is in Case 1 or Case 3. The very 'nature of scientific experimentation 
requires frequent evaluation of experiment outputs with readjustments of 
inputs to obtain the desired results. Evaluation of outputs often requires 
years of education, training, and experience available only through the 
dedicated scientist, Experimentation time availability coupled with the 
inherent problems of verbal communication required in Case 2 does not allow 
the crewmen to provide an acceptable quality of return for the experiments. 



The required scientific knowledge can partially be translated to onboard 
operations by increasing crew size (allowing more time per experiment), 
providing extensive crew training, and providing complex automated 
scientific data processing and evaluation programs. These approaches 
increase the cost yet still fail to give the same degree of scientific return 
as available through the well-informed ground-based scientist of Case 1 and 
Case 3. 

Case 3 also requires five crewmen, however, utilization is much lower. 
With more in-depth analyses, one crewman may be eliminated for this case, 
leaving two crewmen on each shift. Having unbalanced shifts may create 
problems in scheduling experiment activity. This could become a real con- 
straint in real-time replanning of flight experiment operation activities 
(e. g. a tar get -of -opportunity surfaces during a shift that has only one pay- 
load crewman on-station). 


For Cases 2 and 3, a very strong relationship exists between crew training, 
onboard software, and quality of scientific data return. It is physically 
impossible for 2 additional crewmen to perform the same level of effort that 
12 to IS extra FOCC personnel perform in Case 1. It is also unreasonable 
to expect that all of the scientific knowledge of those 12 to 15 persons could 
be transferred to the flight crew. Some of the difference may be made up by 
additional onboard software to handle the routine tasks during experiment 
operations. Increased training will also increase the quality of experiment 
returns. 


Several iterations were made that increased both software and training; 
however, many experiments still had unacceptable levels of quality for Case 2 
In Case 3, those experiments that were unacceptable in Case 2 where 
changed to utilize the FOCC as in Case 1. The requirements for increased 
crew training and the increased complexity of onboard hardware and/or soft- 
ware required by Case 2 would minimize the flexibility for changing payloads 
late in the prelaunch preparation phases. 

The increased demand for added hardware, software, and crew to support 
Case 2 may significantly deplete STS-provided resources for payload support. 
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Case 2 would tend to increase weight, power consumption, data processing, 
and habitation support usage. The result o£ these demands may necessitate a 
decrease in payload -carrying capability. The introduction of the more 
sophisticated payloads beyond those studied for Spacelabs 1 and 2 would 
accentuate this problem. 

Spacelab 1 Onboard Substantiating Data 

Table 1-3-18 depicts the next lower level of data that went into preparation 
of Table 1-3-16. It shows the man-hours of effort which are needed to 
prepare crew requirements and procedures and to complete the necessary 
crew training for the payload flight crew of Spacelab 1. The quantities were 
derived from factors based on experiment duration (D), complexity (C), and 
repetition (R.) along with the quantity of crewmen involved. 

Man-hours for staffing was based on the quantity of crewmen and duration 
of the experiments. This technique of staff estimating is in accordance with 
the ground rules; however, it does not account for the real costs of having 
astronauts on the payroll. Accounting for these costs will drive Cases 2 
and 3 higher and make them less viable. 

3. 3, 2.3 Spacelab 2 Mission 

Spacelab 2 Onboard Comparison of Cases 

The crew activity delta man-hours for each case was shown in Table 1-3-16. 
The most significant components of crew activity are development of crew 
requirements and procedures and especially crew training. The case 
relationships are exemplified by ratios of these efforts for Cases 2 and 3 to 
Case 1. The ratios to Case 1 for requirements development are 2. 2 for 
Case. 2 and 1. 5 for Case 3. The ratios are the same for procedures 
development. The ratios to Case 1 for training are 2. 8 for Case 2 and 1. 8 
for Case 3 . The prime driver that causes the training ratio to be higher 
is the greater crew involvement (greatest in Case 2 and least for Case 1). 

Table 1-3-19 shows the man- loading required for the nine experiment group- 
ings aboard Spacelab 2. This table was used in conjunction with the Strawman 
time line to integrate the real-time man- loading requirements through out 
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Table 1-3-18 

SPACELAB 1 ONBOARD -RELATED MAN-HOURS FOR EXPERIMENTS 


Crew Procedures Requirements Training 

Size Experiment ~ Man-Hours ~ Man-Hours -Man-Hours 

Case Duration : 


Experiment ; 

1 

2 

3 

Hour 

■ i ; 

2 

3 

1 

2 

3 

1 

2 

3 

i. 

AP-09 

3 

5 

5 

6.6 

105 

73 

53 

20 

14 

10 

18 

240 

112 

2. 

AP-13 

3 

5 

5 

16.7 

48 

96 

80 

9 

18 

15 

36 

288 

160 

3, 

ST-31 

3 

5 : 

5 

8.8 

64 

115 

89 

12 

22 

17 

48 

360 

176 

4. 

EO-01 

3 

5 

5 

19.3 

129 

216 

216 

24 

41 

41 

102 

648 

432 

5. 

LS-13 

3 

5 

5 

12.2 

68 

109 

151 

13 

21 

28 

54 

336 

192 

6. 

APE-01 

3 

5 

5 

24. 8 

48 

127 

127 

9 

24 

24 

174 

384 

256 

7. 

SPE-80/85 

3 

5 

5 

56. 4 

72 

289 

108 

14 

54 

20 

156 

864 

168 

8. 

SPE-01 

3 

5 

5 

6.2 

51 

91 

91 

10 

17 

17 

252 

288 

192 

9. 

EOE-01 

3 

5 . 

5 

5.2 

26 

43 

43 

5 

8 

8 

24 

144 

96 

10. 

APE-07 

3 

5 

5 

15. 0 

120 

168 

120 

23 

32 

23 

90 

504 

240 

11. 

STE-10 

3 

5 

5 

20.3 

65 

163 

129 

12 

31 

24 

30 

312 

160 

12. 

ASE- 10 

3 

5 

5 

4.3 

28 

41 

28 

5 

8 

5 

24 

144 

'64 

Experiment 

Total 





824 

1,531 

1,235 

156 

290 

232 

1,008 

4,512 

2,248 
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Table 1-3-19 _ 

SFACELAB 2 FLIGHT PAYLOAD CREWMEN UTILIZATION©© 


Case 

Groupings 1 2 3 


1. 

SC SYN 

0.1 

0.2 

0.2 

2. 

SC PRO 

0. 1 

0. 2 

0. 2 

3. 

PHOTO 

0.2 

0.2 

0.2 

4. 

EUY/PH 

0, 1 

0. 1 

0. 1 

. 5. 

SKY TV 

0.4 

0.4 

0.4 

6. 

S CAM 

0.3 

0.3 

0. 3 

7. 

TRS 

0 

0 

0 

8. 

M Slew© 

1. 0 

1.0 

1. 0 

9. 

I Slew© 

1.0 

1. 0 

1. 0 

(T) Pointing required for all cases. 



(2) Support utilization 

is only 0, 1 man 

(after reslewing}. 



During experiment operations (higher duration activation, 

deactivation, etc* } 

*• . 




the flight. Each hour was assessed to determine the total quantity of crew- 
men required to perform all crew functions. The results indicate that 
three crewmen are required for all three cases. 

The Case 1 crew activity requirement for three men was in agreement with 
the Strawman document^. Unlike Spacelab 1, the schedule and the quantity 
of experiments allow a reasonable utilization of the three crewmen. 

Case 2 also showed a requirement for three crewmen; however, a much 
higher utilization is required. That high-utilization rate app roaches the 
limit, but by minor changes and/or minor Orbiter crew utilization, the 
three crewmen can fulfill the crewmen requirements. 

Case 3 also utilized three crewmen, but at a more relaxed utilization rate. 
Use of the Orbiter crew is not required for this case. 

^Spacelab 2, Strawman, MSFC, SE -012-022-28, December 1976. 
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Spacelab 2 Onboard Substantiating Data 

Table 1-3-20 depicts the next lower level of data that went into preparation 
of Table 1-3-16. It shows the man-hours of effort which are needed to 
prepare crew requirements and procedures and to complete the necessary 
crew training for the flight payload crew of Spacelab 2. The quantities were 
derived from factors utilizing experiment duration (D), complexity (C), and 
repetition (R) along with the quantity of crewmen involved. 

Man-hours for staffing were based on the quantity of crewmen and duration 
of the experiments. As stated earlier, it does not account for the real costs 
of flying personnel which would drive Cases 2 and 3 higher and make them 
less viable. 

3 . 4 SYST EM MODIFICATIONS 
3. 4.1 Hardware Modifications 
3. 4. 1. 1 Spacelab 1 

This study identified no hardware modification requirements for Spacelab 1. 
The POCC baseline plan is adequate for ground support (control, monitoring, 
and analysis) of the experiment operations in all three study cases. Flight 
systems and experiment hardware design requirements are adequate to 
support mission activities for each of the study cases. However, in Case 2, 
increased use of the Spacelab experiment computer resulted in near saturation 
of the computer's capacity. Added experiment or operational complexity of 
later missions may result in a requirement for additional computer capacity. 

3.4. 1,2 Spacelab 2 

The POCC baseline plan, as for Spacelab 1, is adequate to support ground 
operations for Spacelab 2. Ground computers will be used to analyae 
experiment scientific data to identify unique solar or spatial phenomena 
(i.e. , solar magnetic fields or stellar extreme UV sources). The consoles 
identified in the POCC will be adequate if experiment support personnel 
(Pis, etc. ) are assigned to specific consoles only at those times that their 
individual experiment is scheduled on the flight time line. 
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Table 1-3-20 

SFACELAB 2 ONBOARD- RELATED MAN-HOURS FOR EXPERIMENTS 


Crew Procedures Requirements Training 



Experiment Case 

i 

Size 

2 

3 

Experiment 

Duration 

Hour 

rsj 

i 

Man-Hours 
2 3 

~ Man-Hours 
1 2 3 

1 

Man-Hours 
2 3 

1 . 

Transition Radi- 
ometer . 
Spectrometer 

3 

3 

3 

279.0 

44 

44 

44 

8 

8 

8 

33 

43 

40 

2. 

Far UV Schmidt 

Camera 

Spectrograph 

3 

3 

3 

12. 5 

12 ' 

24 

12 

3 

5 

3 

9 

23 

11 

3. 

Extreme UV 

Imaging 

Telescope 

3 

3 

3 

12.4 

9 

29 

29 

2 

6 

6 

7 

29 

26 

4. 

Skylark Cosmic 

X-Ray 

Telescope 

3 

3 

3 

110.0 

35 

104 

70 

7 

21 

13 

26 

103 

62 

5. 

LLL TV 

3 

3 

3 

no. o 

35 

104 

52 

7 

21 

10 

26 

103 

48 

6. 

65-cm 

Fhotoheliograph 

3 

3 

3 

136. 0 

65 

196 

65 

12 

37 

12 

49 

191 

60 

7. 

Solar Monitor 
Package 

3 

3 

3 

123. 6 

197 

396 

297 

37 

74 

56 

148 

380 

266 

8. 

Soft X^Ray 
Telescope 

3 

3 

3 

123. 6 

79 

159 

159 

15 

30 

30 

59 

155 

143 

9. 

Lyman- Alpha 
White- Light 
Coronagraph 

3 

3 

3 

47.2 

76 

151 

76 

14 

28 

14 

57 

147 

68 

10. 

High- Sensitivity 
X-Ray Burst 
Detector 

3 

3 

3 

136. 6 

88 

176 

176 

16 

32 

32 

66 

170 

157 

Exp 

eriment Total 





640 

1,383 

980 

121 

262 

184 

480 

1, 344 

881- 


There is no requirement for additional onboard hardware to support study 
Cases 1 and 3. This is because scientific data can be analyzed and monitored 
by ground computers and personnel. However, in Case 2, it is recommended 
that additional hardware be incorporated into specific experiments. This 
hardware is necessary to increase the scientific return of these experiments 
and to ensure that any unique phenomena occurring during the mission will be 
observed. To determine which of the Spacelab 2 experiments would be 
candidates for additional hardware to increase the scientific return, the data 
output of each was analyzed to identify those which can be monitored on-orbit. 
Four experiments (65-cm photoheliograph, soft x-ray telescope, white-light 
coronagraph portion of the La/WLC experiment, and far UV Schmidt camera/ 
spectrograph) record the scientific data on film which will be processed and 
analyzed after the mission. Three experiments (high-sensitivity X-ray burst 
detector, Skylark cosmic X-ray telescope, and LLL TV) transmit data which 
is not processed in real time but is analyzed by more rigorous methods. 

Four experiments, solar monitor package, Lyman-Alpha portion of the 
IjG'/WLC experiment, transition radiation spectrometer, and extreme UV 
imaging telescope, should be considered for the addition of special ha .’dware 
for increasing the scientific return for Case 2, 

The solar monitor package, along with other data acquisition, measures the 
solar magnetic field. It is desirable to monitor the output of the magneto- 
graph for detection of unique magnetic fields which might require further 
investigation during a data run. After this signal is digitized aud routed out 
of the experiment, the data cannot be continuously monitored by onboard 
computers to detect magnetic fields. It is proposed for Case 2 that a detec- 
tor be designed and incorporated into the experiment. This detector will 
monitor the sensor output, and, by synchronization with the sensor, will 
locate sources of unique magnetic fields. The detector -will provide a signal 
to the Orbiter AFD to alert the flight crew of the occurrence and location of 
the magnetic field. 

The Let sensor monitors the sun in the 1216 A wavelength. During experi- 
ment operations, this sensor will detect solar phenomena which could require 
further investigation. In Cases 1 and 3, the data will be transmitted to the 
ground for computer analysis in the FOCC* However, in Case 2, where there 



is no link to the POCC, all data must be monitored onboard. Continuous 
monitoring and analysis of the output of the La sensor would not be compatible 
with flight computer usage. It is recommended that the output of the La 
sensor be monitored by a specially designed detector which would indicate 
to the flight crew the presence and location of any unique events of the sun. 
Then, using the voice link with the PI, the crew could determine if additional 
data- taking should be planned. 

The transition radiation spectrometer is an experiment which operates con- 
tinuously throughout the mission and is used to determine flux and energy 
spectra of cosmic protons and electrons. Ground monitoring computers in 
the POCC can be used to analyze the continuous stream of data to identify 
spatial locations where the concentration of these phenomena might require 
additional data acquisition. In Case 2, this continuous data link to the POCC 
is not available, consequently, the detection of these radiation sources must 
be accomplished onboard. Monitoring of this data would limit flight computer 
support of other experiments. Therefore, it is recommended for Case 2 that 
an energy detection system be incorporated into the experiment to monitor the 
spectrometer output and alert the flight crew of the presence of unique radia- 
tion. sources. 

The output of the extreme TJV imaging telescope, used to obtain extreme UV 
images of stellar objects, is transmitted to the POCC for analysis in Cases 1 
and 3. The analysis will identify the existence of extreme UV sources which 
could require additional data acquisition. In Case 2, where data monitoring 
is accomplished entirely onboard, it would impact the operation of other 
experiments to use the experiment computer to continuously monitor the 
output of this experiment. Consequently, for Case 2 it is recommended that 
a detector be developed and incorporated into the experiment which would 
monitor the telescope output and alert the flight crew of the location of any 
unique extreme UV sources. With the assistance of the PI, through the voice 
link, it can be determined if additional runs should be scheduled to acquire 
data on the extreme UV sources. 


3, 4, 2 Software Modifications 

Software cost deltas for both the onboard and the POCC functions were 

determined for each of the three cases. In addition, a Case 2 onboard option 

involving automating some of the operator functions was also estimated. 
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Experiment computer capacity was assessed for adequacy in each of the trade 
cases. The requirements were determined from estimates of the total num- 
ber of program instructions, sizing a worst-case second, and the computer 
operations per second. 

Expei-iment data management functions were estimated in seven functional 
categories for Spacelab 1 and Space lab 2 for each case and converted to 
software program instructions and computer operations per second. These 
estimates were based on experiment and instrument descriptions and on 
discussions with investigators experienced with each experiment. The 
categories were: 

A. Limit check and alert operator of anomalies {parameter per 
second). 

B. Gather and format data for telemetry (TM) - i’kBFS) this did not 
include TM data sent directly to the HRM. 

C. Gather data and convert for display or CRTs (parameters) - update 
once per second maximum. 

D. Send commands to experiment - either preprogrammed, uplinked, 
or operator initiated - (CMDS). 

E. Communications with the Orbiter computer - uplink commands, data 
transfer, etc. {words per second). 

F. Data r eduction and evaluation - (functional definition). 

G. Special computations - (functional definition). 

A summary of the data after conversion to program instructions and opera- 
tions per second is shown in Tables 1-3-21 and 1-3-22. 

For the automation on Case 2, scientific data was monitor ed by the experi- 
ment computer to determine if the experiment was operational and data of 
some quality was being transmitted on the downlink. It reflects an attempt 
to reduce the crew work load required to accomplish the mission. It was not 
intended to evaluate the scientific data as a FI on the ground would be 
expected to do. 

The standard programs available (limit check, I/O, D DU /KB message 
program, data conversion to engineering units, telemetry data formating, 
and other utilities) will handle most of the experiment housekeeping functions. 



Table 1-3-21 

PROGRAM INSTRUCTIONS 



Type 

Case 1 

Case 2 

Case 3 

Spacelab 1 Basic 

ENG 

14, 974 

15,000 

15,003 

Pointing Data 

SYS ANA 

- 

500 

500 

Heat Rate 

SYS ANA 

- 

100 

100 

Automated 

ENG 


15,343 

- 


SYS ANA 

- 

5, 183 

“ 

POCC Spacelab 1 
Pointing Data 
Heat Rate 

ENG 

17, 152 
500 
loo 


13, 293 

Spacelab 2 Basic 

ENG 

4, 041 

5, 981 

5, 981 

POCC Spacelab 2 

ENG 

7,386 

- 

5,376 

EPS and MPM Pointing 

SYS ANA 

400 

- 

- 


Table 1-3-22 

EXPERIMENT COMPUTER OPERATIONS PER SECOND 

Case 1 Case 2 Case 3 

Spacelab 1 (All Experiments) Basic 60, 4.4K ^168. 85K ^165. 65K 

Automated (All Experiments) - 139. 4K 

Worst Case 4 Experiments, (2) Basic - 137. 75K - 

Automated Worst Case 4 Experiments - 86.4K 

(2) (3) 

Spacelab 2 (All Experiments) Basic 85. 92K 100. 56K 100, 56K 


Note: 260k OPS/ sec available. 

(!) Includes some high-rate scientific data on the experiment computer TM 
downlink. 

(2) Experiments AP-09, EO-01, LS-13, and APErOl. 

(3) No more than two of these experiments are ever on together. 
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It is assumed the experimenter will provide the data (parameters, limits, 
etc. ) required for these programs to operate. Any closed-loop control 
program would have to be entirely supplied by the experimenter*. For ease 
of development, it would seem that most closed-loop control would be self- 
contained within the experiment. One experiment (EO-Ol, Spacelab 1) used 
the experiment computer for closed-loop control. 

Similarity between Cases 1, 2, and 3 is created by: 

A. The downlink TM being required for ground recording for offline 
analysis (Cases 1, 2, and 3) in addition to its use at POCC (Cases 1 
and 3). 

B. The monitoring and limit test of housekeeping parameters are 
required during TM blackout periods. This results in programming 
for onboard monitoring and limit testing for Cases 1 and 3 in addi- 
tion to ground monitoring and limit testing. 

C. It is felt that if the onboard displays (CUT s) are utilized for any 
phase of experiment operations, any parameter available to the 
experiment computer will be available to the CRT display. The 
CRT is used in some phase, in all cases. From a programming 
standpoint, the amount of information entered for display use is 
dependent on the experiment and not on the trade case. 

Certain functions were not included in the onboard software for any case. 

A. Resource Planning. The resource analysis of any online rescheduling 
of experiment operations was ground ruled as being done on the 
ground. The onboard computer capacity is not adequate for this type 
of number- crunching program. 

B, Pattern Recognition of Scientific Data to Identify Events. This type 
of program would exceed the capability of the onboard computer and 
be very expensive to prepare. 

With the present definition level of the experiments and the indication that 
the experiments seem to be mostly self-contained, the CDMS computer system 
appears capable of handling the computing load for all experiments. For the 
basic operations for both Spacelab missions, the margin (OPS/sec) is ade- 
quate when all experiments are operated simultaneously. For Case 2, when 
the automation is added to the basic operation, the available OPS/sec are 



exceeded. As shown in Table 1-3-22, the worst case four experiments, basic 
and automated, were estimated and their sum is within the available (OPS/sec) 
A large margin is established because a review of the Spacelab 1 time line 
revealed no more than two of these experiments are ever operated together. 


Memory (K words) for the experiment computer were estimated, based on the 
instructions and functions for each experiment. The results are summarized 
in Table 1-3-23. It was assumed any problem with rapid access memory 
could be solved by segmenting the operational program and bringing in seg- 
ments from mass memory as required. If this is required, it will impact 
the I/O and reduce the available OPS/sec in the central processing unit 
(CPU). As the experiment computer has direct memory access (DMA), 

I/O should not be a problem unless too many memory access cycles are 
stolen from the CPU during DMA utilization. 


Table 1-3-23 


EXPERIMENT COMPUTER ACTIVE MEMORY ESTIMATE (K WORDS) 


Spacelab 1 

Case 1 

Case 2 
(Automated) 

Case 3 

All Experiments 

71 

229 

89 

Worst 4 Experiments^ 

32 

104^ 

41 


Note: Capacity (at 64%) = 41K Words 

(1) Experiments AF-09 and AP-13, APE-01, and LS-13 
(EO-Ol operates alone or with SPE-85 only). 

(2) Assumed accommodated by accessing program segments from mass 
memory, only as required. 


Standard Spacelab programs are assumed to exist for limit checking, CRT 
display, uplink commands, and TM formatting. The engineering type of 
programmer enters information into an existing program using formats 
defined by the existing programs. The system analyst works from basic 
requirements and designs programs to accomplish specified functions. For 
the POCC software, the same number of instructions were used for similar 
functions accomplished on the ground and onboard. 


The instruction conversion factors were as shown in Table 1-3-24. 
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Table 1-3-24 / 

INSTRUCTION CONVERSION FACTORS (HOURS /INSTRUCT ION) 



Onboard Computer 

POCC Computer 

System Analyst 

2.7 

0.68 

Engineering Data 

0. 54 

0. 14 


This conversion factors are for checked-out instructions written in a higher 
order language. They also reflect an additional complexity factor of four for 
the onboard programs which is primarily involved with the test and integration 
with the onboard system. 

The total software hours were derived from the estimated programming 
instructions and conversion factors. These are shown in Table 1-3-25 for 
each mission and case. 

Special programs for evaluating and monitoring data (heat-rate calculations) 
or aiding operator decisions (experiment pointing) must be written for the 
onboard experiment computer for Case 2 and for the POCC (computers) for 
Case 1. In either case, the basic programs would be the same. The cost 
deltas would occur primarily in the development and integration process. 

This could be heavily influenced by the availability of compatible computer 
systems at the experimenter's facility. For the studied missions, very few 
special programs were identified. 

3. 5 COST ANALYSIS 

3. 5.1 Cost Approach 

A rough-order-of-magnitude (ROM) cost estimate was made of all hardware 
and software modifications required to support real-time mission operations 
for each of the three assumed cases of onboard versus ground real-time 
mission operations (see Subsection 3. 4 for definition of hardware and 
software modifications). 

For cost estimating, the baseline system was assumed to be the current 
system design and POCC and NASCOM facilities presently planned for early 
Spacelab missions. All costs were estimated as differences to this baseline. 



Table I-3-Z5 
SOFTWARE HOURS 



Typb 

Case 1 

Case 2 Case 3 

Onboard Software Spacelab 1 

Basic (No Special Automation) 

ENG 

8, 138 

8, 152 

8, 153 

Pointing Data 

SYS ANA 

- 

1, 351 

1, 351 

Heat Rate 

SYS ANA 

- 

270 

270 

Automated (22, 347 -Hr Total) 

ENG 

SYS ANA 


8, 339 
14, 008 


POCC Software Spacelab 1 Basic 

ENG 

2, 334 

- 

1, 809 

Pointing Data 

SYS ANA 

340 

- 

- 

Heat Rate 

SYS ANA 

68 


- 

Onboard Software Spacelab 2 





Basic 

ENG 

2, 196 

3, 251 

3, 251 




Automated 

scientific 

data 

monito ring 
is met by 
added experi 
ment hard- 
ware 


POCC Software Spacelab 2 

ENG 

1, 005 

- 

731 

IPS and MPM Pointing 

'j 

SYS ANA 

272 

Should be 
part of 
Spacelab 
subsystem 



Operations support costs were estimated in total man-hours for POCC 
operations and in delta (A) man-hours to a Case 1 baseline for onboard 
operations. 


A cost work breakdown structure was established as shown in Figures 1-3-35 
and 1-3 -36. 


The costing exercise was governed by the following ground rules. 1 

A. Accommodations for onboard data processing requirements exceed- 
ing the capability of the Spacelab CDMS were assumed as part of 
each instrument design for all cases. 

./ 
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POCC 

RELATED 

COSTS 


f-POCC (OSF/JSC) 

• DATA PROCESSING 

• DATA DISPLAY 

• COMMAND AND CONTROL 

• SPECIAL COMPUTATIONS 

• OPERATION AND 
MAINTENANCE OF ADDED 
iQUIPMENT 

•NAS*X)M (OTDA/GSFC) 

• D.Vi A TRANSMISSION 
EQUi°MENT 

• OPERATION AND 
MAINTENANCE OF 
ADDED EQUIPMENT 




HARDWARE 



AS 


(DESIGN, 
MOD. TEST) 

AS 

SOFTWARE 

(AHRAND 

SKILLS) 

OPERATIONS 


DERATIONS SUPPORT 
(OSF/JSC) 

• DATA PROCESSING 

3 COMMAND PROCESSING 

• SPECIAL COMPUTATIONS 


TOTAL 

MAN-HOURS 


^EXPERIMENT OPERATIONS 
(OSS/PIs) 

• REQUIREMENTS DEVELOPMENT 

• OPERATING PROCEDURES 

• TRAINING 

• POCC STAFFING 

l-PAYLOAD INTEGRATION 
(OSS/MSFC) 

• REQUIREMENTS DEVELOPMENT 

- EQUIPMENT REQUIREMENTS 

- DATA ACQUISITION 
SUPPORT REQUIREMENTS 

- SOFTWARE REQUIREMENTS 

- OPS SUPPORT REQUIREMENTS 

- PROCEDURE REQUIREMENTS 

• PROCEDURE INTEGRATION 

• TRAINING 

• POCC STAFFING 


Figure 1-3*35. Cost Work Breakdown Structure, POCC Related Costs 


ONBOARD 
RELATED COSTS 
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HARDWARE 

A $ 


AS 


(DESIGN. MOD, TEST) 

SOFTWARE 

(AHRAND 

SKILLS) 

OPERATIONS 



[-EX PERIMENT MODIFICATIONS (OSS/PI) 

• AIRBORNE EQUIPMENT 

- INSTRUMENTATION 

- DATA PROCESSING 

- DATA DISPLAY 

- CONTROL 

- SUPPORT SYSTEMS (POWER, ETC.) 

- CHECKOUT REQUIREMENTS 

• GROUND SUPPORT EQUIPMENT 

- SIMULATION AND CHECKOUT 

- SPECIAL TEST 

- HANDLING 

•SPACELAB/ORBITER MODS 
(OSF/MSFC/JSC) 

• APT PLIGHT DECK PSS ADDITIONS 

• SPACE LAP SUPPORT SYSTEMS 

• GROUND SUPPORT EQUIPMENT 

- SIMULATION AND CHECKOUT 
EQUIPMENT MODS 


EXPERIMENT (OSS/PI) 

• AIRBORNE SOFTWARE 

- DATA REDUCTION AND DISPLAY 

- DATA ANALYSIS 

- OPERATIONAL PROCEDURES 

- DATA STORAGE AND RECALL 

• GROUND SOFTWARE 

- SIMULATION, CHECKOUT, 
DIAGNOSTIC 

■SPACELAB/ORBITER (OSF/MSFC/JSC) 

• AIRBORNE SOFTWARE 

- INTEGRATED PAYLOAD DATA 
REDUCTION AND DISPLAY 

- REPLANNING/RESOURCES 
EVALUATION 

- OPERATIONAL PROCEDURES 

- DATA STORAGE AND RECALL 

• GROUND SOFTWARE 

- SIMULATION, CHECKOUT, 
DIAGNOSTIC 


MAN-HOURS 


-MISSION OPERATIONS 

• OPERATIONS REQUIREMENTS 
DEVELOPMENT (OSS/MSFC) 

- EQUIPMENT REQUIREMENTS 
DEFINITION 

- SOFTWARE REQUIREMENTS 
DEFINITION 

- OPERATIONS SUPPORT 
REQUIREMENTS DEFINITION 

• CREW ACTIVITY (OSS/MSFC/JSC) 

- OPERATIONS DEFINITION 

- PROCEDURES DEVELOPMENT 

- TRAINING 

- REAL TIME OPEARTIONS 

•GROUND OPERATIONS 
(OSS/PI /MSFC/KSC) (PROCEDURE 
CHANGES AND A TASK EFFORT) 

• LEVEL IV SUPPORT 

• LEVEL III, II, I SUPPORT 


Figure 1-3-36. Cost Work Breakdown Structure, Onboard Related Costs 
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B. All costs were ROM normalized to FY '77 dollars. 

C. Costs were determined as increments to a baseline system. The 
baseline system was considered to be the current system design and 
POCC and NASCOM facilities presently planned for early Spacelab 
missions. 

D. POCC facility deletions that are possible for Case 2 {minimum 
POCC) and Case 3 (minimum systems POCC) were not costed. 

E. Onboard equipment reductions were not considered for any of the 
three cases, 

F. Utilization or operating costs were expressed in man-hours. 
Man-loading will include both Government and contractor services. 

G. The basic operations and maintenance of POCC facilities, com- 
munications, and ground data systems were assumed to be constant 
for all cases, and were provided wholly by JSC as the POCC host. 

H. Real-time software used in POCC computers were to be developed, 
maintained, and funded by JSC, Software for offline analysis and 
software for user -provided equipment were to be user provided, 
maintained, and funded. 

I. Computations support for payload activity replanning were to be 
performed by MSFC computer using terminals located in the POCC 
and the software system used for premission planning. 

J. Continuous POCC manning was requir ed throughout the mission for 
all cases, but manning levels were dependent upon specific payload 
activity requirements. 


3, 5. 2 Hardwar e Costs 

The only hardware modifications required were in support of Case 2 of the 
Spacelab 2 mission. The solar monitor package, Lyman- Alpha portion of 
the La/WLC experiment, transition radiation spectrometer, and the extreme 
UY imaging telescope were modified to add detection systems to enable 
onboard monitoring of their output. See Subsection 3. 4. 1 for the description 
of these modifications. The ROM costs for these modifications were arrived 
at by estimating the modification as a percentage of total instrument design. 
Design complexity, verification requirements, etc. , were considered in 
arriving at this percentage factor. The final cost (see Table 1-3-26) was 
arrived at by multiplying this factor times the total cost of a similar instru- 
ment as actual instrument costs were unavailable. 
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Table 1-3 -26 

SPACELAB 2 HARDWARE MODIFICATION COSTS 


Solar Monitor Package 

$ 54,000 

Transition Radiation Spectrometer 

$ 54,000 

Lyman Alpha 

$ 93,000 

Extreme UV Imaging Telescope 

$ 93,000 

Total 

$294, 000 


3.5.3 Software Costs 

Software modifications were required to support both, onboard and POCC 
operations. These modifications included limited onboard monitoring of 
scientific data, onboard automation of certain functions to reduce crew 
workload, and limited ground analysis of scientific data for Cases 1 and 3. 

See Subsection 3. 4. 2 for a definition of the software modifications and a 
breakdown of the software man-hour costs. 

Man-hours were arrived at by determining the number of instructions 
required for each modification and converting this to man-hours. Man-hours 
were then converted to dollars using a factor of $30 per hour for engineering 
and $20 per hour for the system analyst efforts. See Table 1-3-27 for softwar 
cost summary. 


Table 1-3-27. 

SOFTWARE MODIFICATION COSTS 



POCC Software 
(£$) 

Onboard Software 
(A$) 

Spacelab 1 



Case 1 

$78, 000 

0 

Case 2 

0 

$563,000 

Case 3 

$54, 000 

$ 33, 000 

Spacelab 2 



Case! 

$36,000 

0 

Case 2 

o 

$ 32,000 

Case 3 

$22, 000 

$ 32, 000 
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3.5.4 Operations Costs 

Mission operations support was estimated in total man-hours for POCC 
operations and in delta man-hours to Case 1 for onboard operations. See 
Subsection 3. 3 for a detailed description of the mission operations support 
tasks and man-hour estimates. See Figure 1-3-37 for a summary of oper- 
ations costs. 

The prelaunch operations cost for integration verification of the airborne 
hardware and software modification are included as part of the total hardware 
and software cost figures. 

3.5.5 Cost Summary 

The final results for hardware,, software, and operations costs are summar- 
ized on Figure 1-3-38. It should be noted that due to the relative simplicity 
of the payloads studied, the currently planned hardware systems for the 
POCC and Spacelab were adequate (except for onboard Spacelab 2, Case 2) to 
support the operations without modification for the three assumed operating 
modes studied. 

Since Case 1, a full data and command centralized POCC was used as a cost- 
ing baseline and requires the most software for POCC operations, the soft- 
ware costs for Cases 2 and 3 were presented as a cost savings over Case 1. 
Note that the operations support is presented as total hours for the ground 
POCC support and in delta hours to a Case 1 baseline for onboard operations. 

The quantitative results of this study indicate that use of the POCC (with 
data processing capability) to support real-time operations would be most 
cost effective. Converting operations hours to dollars (at $30 per hour), 
the total cost differences between Cases 1 and 3 were about $100, 000 for 
either mission. Case 2 costs were higher ($200, COO to 500, 000). An 
evaluation of the more complex downstream Spacelab payloads, which 
were not studied in this analysis due to a lack of definition, may provide 
more significant cost differences. 
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STAFFING PERSONNEL 

TOTAL OPERATIONS SUPPORT*** 


j POCC* 

MSFC/PIs 

FLIGHT** 

CREW 

POCC 

(TOTAL HOURS) 

ONBOARD 
(A HOURS) 

SPACELAB 1 
(7 DAYS) 

CASE 1 

20738 

3 

10, 884 

0 

case a 

14/23 

5 

5,418 

4,591 

CASE 3 

14/26 

5 

6,573 

1,851 

SPACELAB Z ; 
112 DAYS) 

CASE 1 

20/32 

3 I 

11,898 

0 

CASE 2 

14/20 

' 3 

7,317 

1,913 

CASE 3 

16/26 

3 ' 

9,603 

869 


•TWO-SHIFT TOTAL 
♦* FOR EXPERIMENT OPERATIONS 

*** STAFFING PLUS REQUIREMENTS DEVELOPMENT, OPERATING PROCEDURES, AND TRAINING 


Figure 1-3-37. Operations Results 



| POCC 

onboard 

TOTAL 

COST* 

(SI 

HARDWARE 

(AS) 

SOFTWARE 

(AS) 

OPERATIONS 

(HR) 

HARDWARE 

(AS) 

SOFTWARE 

(A$) 

OPERATIONS 

(AHR) 

CASE 1 

0 

D 

10,880 

0 

a 

0 

$328*000 

SL-1 CASE 2 

G 

($78,000) 

SAVINGS 

S.420 

0 

$563,000 

4,590 

$788,000 

CASE 3 

0 

($24,000) 

SAVINGS 

6,570 

0 

$33,000 

1,850 

$262,000 

CASE 1 

a 

0 

11,900 

0 

0 

0 

$357*000 

SL-2 CASE 2 

0 

($36,000) 

SAVINGS 

7,320 

$294,000 

$32,000 

1,910 

$567,000 

CASE 3 

0 

($14,000) 

SAVINGS 

9,700 

0 I 

j 

$32,000 

870 

$332,000 


•OPERATIONS HOURS CONVERTED TO DOLLARS USING S30/HR 
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Figure i-3-38. Onboard vs Ground 
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3. 6 QUALITATIVE ANALYSIS 

Qualitative evaluation of several additional factors should also be considered 
in arriving at a decision as to the degree of onboard versus ground-based 
operations. A listing of these factors follows. 

A. Scientific Return 

B. Operational Flexibility 

C. Onboard Equipment Resources 

D. Flight Crew Utilization 

E. Growth Potential 

F. Reliability 

G. Safety 

H. Marketability 

These factors are very difficult to quantify to allow for cost comparisons. 
However, a qualitative analysis was conducted for several of the more 
significant factors. 

3, 6. 1 Scientific Return 

It is not possible to get the same experiment scientific return in Case 2 as it 
is in Case 1 or Case 3. The very nature of scientific experimentation 
requires frequent evaluation of experiment outputs with readjustments of 
inputs to obtain the desired results. Evaluation of outputs often requires 
years of education, training, and experience available only through the 
dedicated scientist. Experimentation time availa, dlity coupled with the 
inherent problems of verbal communication required in Case 2 preclude 
the ground-based scientist of providing the most effective interface with his 
experiment. 

The required scientific knowledge can partially be transmitted to onboard 
operations by (1) increasing crew size (allowing more time per experiment), 
(2) providing extensive crew training, and (3) providing complex automated 
scientific data processing and evaluation programs. These approaches 
increase the cost yet still fail to give the same degree of scientific return as 
available through the well-informed ground-based scientist of Case 1 and 
Case 3. 
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Relative scientific data quality assessments were performed for each of the 
experiments on the two missions. From these assessments, it can be 
determined if experiment operations in each of three cases can be performed 
and evaluated to produce the best scientific return possible. In this effort. 
Case 1 was used as a reference for evaluating Cases 2 and 3. As an example, 
experiments, which gather scientific data solely on film (e. g. , metric camera 
and soft x-ray telescope) would not have a reduced scientific return because 
the data is not real-time analyzed. Other experiments which do not record 
data on film provide, in one form or another, the capability for real-time 
analysis which could identify changes in experiment operation as the mission 
progresses to increa se the scientific return of the experiment. This scientific 
quality indicates (1) the ability of the flight crew, in Case 2, to perform this 
real-time data analysis with the equipment provided onboard or (2) the ability 
of the flight crew and the ground personnel, in Case 3, to perform real-time 
data analysis within the constraints of this case. These assessments are 
presented in Tables 1-3-28 and 1-3-29- Note that the average numbers of 
these tables do not consider the relative value of the various experiments and 
therefore do not necessarily represent the scientific return for the total 
mission. 

3 . 6. 2 Operational Flexibility 

The ability to monitor and control payloads from the ground (Cases 1 and 3) 
provides a significant degree of flexibility not available in Case 2. Should 
onboard problems (e.g. , crew sickness or diversion of attention from one 
payload to problem investigation of another payload or STS support system) 
preclude accomplishment of scheduled payload activities, ground control could 
be assumed with a potential of salvaging significant payload operations. 

The requirements for increased crew training and the increased complexity 
of onboard hardware and/or software required by Case 2 would minimize the 
flexibility for changing payloads late in the prelaunch preparation phases. 
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Table 1-3-28 

SPACELAB 1 - RELATIVE SCIENTIFIC QUALITY ASSESSMENT 




Case 1 
(Reference) 

Case 2 

Case 3 

1. AF-09 

Electron Accelerator 

1.0 

0. 5 

1.0 

2. AP-13 

LLL TV 

1. 0 

0.5 

1. 0 

3. ST-31 

Drop Dynamics 

1.0 

0.7 

0.9 

4. EO-Ol 

Cloud Physics Lab 

1.0 

0.7 

1.0 

5. LS-13 

Minilab 

1.0 

0. 8 

1.0 

6. APE-01 

LIDAR 

1.0 

0.6 

0.9 

7. SPE 80/85 

Space Processing 

1.0 

0. 6 

1.0 

8. SPE- 01 

Free-Flow Electrophoresis 

1.0 

0. 8 

1.0 

9. EOE-01 

Metric Camera 

1.0 

1.0 

1.0 

10. APE- 07 

IR Radiometer 

1.0 

0.7 

1.0 

11. STE-10 

Heat Pipe 

1.0 

1. 0 

1. o 

12. ASE-01 

Wide-Field Galactic Camera 

1. 0 

0.9 

1.0 


Average 

1.0 

0.73 

0.98 


Table 1-3-29 

SPACELAB 2 - RELATIVE SCIENTIFIC QUALITY ASSESSMENT 



Case 1 
(Reference) 

Case 2 

Case 3 

1, 65 -cm Photo heliograph 

1.0 

1.0 

1.0 

2. Solar Monitor Package 

1.0 

0.8 

1.0 

3. Soft X-Ray Telescope 

1-0 

1.0 

1.0 

4. Lyman-Adpha White-Light Coronagraph. 

1.0 

0.7 

1.0 

5. High-Sensitivity X-Ray Bur *it Detector 

1.0 

0.9 

1.0 

6. Skylark Cosmic X-Ray Telescope 

1.0 

0. 8 

r . 

O 

7. LLL TV 

• 1.0 : 

0.7 

1.0 

8. Far UV Schmidt Camera/Spectrograph 

1. 0 

1.0 

1.0 

9. Transition Radiation Spectrometer 

1.0 

0. 6 

1. 0 

10. Extreme UV Imaging Telescope 

1.0 

GO 

• 

O 

1. 0 

Average 

1.0 

0.83 

1. 0 
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3. 6.3 Onboard Resources 

The increased demand for added hardware/ software, and crew to support 
Case 2 may significantly deplete STS-provided resources for payload support. 
Case 2 would tend to increase weight, power consumption, data processing 
resources, and habitation support resources. The result of these demands 
may necessitate a decrease in payload-carrying capability. The introduction 
of the more sophisticated payloads beyond those studied for Spacelabs 1 and 2 
would accentuate this problem. 

3.6.4 Flight Crew Utilization 

There are certain payloads where an increase in crew utilization can result 
in a reduction of ground support requirements and still produce the same 
scientific return. Recognizing these situations and planning accordingly 
should result in an overall reduction of real-time operational costs. This 
increased crew utilization is reflected in Case 3 of this study. The crew 
activity required to support Case 2 was determined to be an extremely heavy 
work load, particularly for the Spacelab i type payloads. 
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Section. 4 

CONCLUSIONS AND RECOMMENDATIONS 

Major conclusions including qualitative evaluation for these missions are 
summarized on Figure 1-4-1. As stated previously, the cost analysis favors 
Case 3. With respect to scientific return, it is not possible to get the same 
experiment science return in Case 2 as in Cases 1 or 3. Extensive flight 
crew education, training, and experience would be required to match the 
knowledge of the well-informed ground-based scientist. In addition, complex 
onboard science processing equipment would have to be added to aid vhe 
flight crew to process data and monitor and control certain experiments. 

Case 1 with maximum ground support should provide the greatest scientific 
return with Case 3 being a very close second. With respect to operational 
flexibility, the ability to monitor and control payloads from the ground and 
onboard (Case 3) provides more flexibility than Cases 1 and 2, Onboard 
problems, such as crew diversions or sickness, could preclude accomplish- 
ment of scheduled payload activities in Case 2. Furthermore, the require - 
ments for increased p rew training and increased complexity of hardware and 
software would minimize the flexibility in Case 2 for changing payloads late, 
in the prelaunch period. The potential loss of ground control because of 
communication difficulties would minimize the flexibility of Case 1, 

With respect to onboard resources, both Cases 2 and 3 will require increased 
onboard weight, power, data processing, and habitation support which will 
reduce STS resources for payload support as well as payload capability. 

Case 2 would impose the greatest impacts. With respect to flight crew 
utilization, the flight crew work load for Spacelab 1 type missions is extremely 
heavy for Case 2. In Case 3, the work load is less and with proper planning 
there could be a reduction in ground support requirements without a decrease 
in scientific return. Case 3 is favored over Case 1 because of increased 
effectiveness during selected payload operations when the value of a hands-on 
operation is exploited. In conclusion. Case 3 was determined to be the 
recommended approach. 



CASE 1 CASE 2 CASE 3 

(MAX (VOICE (PARTIAL 

POCC) POCC) POCC) 


COST V 

(HARDWARE, SOFTWARE, OPERATIONS) 

SCIENTIFIC RETURN V 

(TRAINING, INFORMATION PROCESSING) 

OPERATION FLEXIBILITY V 

(FLTOPS SCHEDULING, PRELAUNCH CHANGES) 

ONBOARD RESOURCES ' V 

(WEIGHT, POWER, DATA PROCESSING, HABITATION SUPPORT) 

FLIGHT CREW UTILIZATION V 

(WORKLOAD, HANDS ON ADVANTAGES) 

OVERALL CONCLUSION - CASE 3 RECOMMENDED 

Figure 1-4-1. Onboard vs Ground Real-Time Mission Operations Conclusions 


Overall recommendations for the onboard versus ground real-time mission 
operations analyses are shown o n Figure 1-4-2. It is recommended that a 
ground crew be used for real-time mission support of selective scientific 
payloads, particularly those that require special data analysis in order to 
continue real-time operations during the mission. The flight crew should be 
used (with backup ground capability) for real-time housekeeping operations of 
experiments to ensure that they are working properly, and to conduct any 
special operations that may be required. Flexibility in the mode of 
operations (onboard versus ground) should be maintained depending upon 
the mission or experiment. Onboard operations will be better for some 
missions and experiments, whereas ground operations will be better for 
others. The outcome is very mission and equipment dependent. Therefore, 
it is recommended that follow-on studies be conducted to evaluate these modes 
of operation for downstream Spacelab missions. Additional study may also 
be advisable to analyze how special payloads groupings could optimize crew 
utilization. 



DIRECT ACTION: 

• USE GROUND CREW FOR REAL-TIME MISSION SUPPORT OF SELECTIVE 
SCIENTIFIC PAYLOADS (SCIENCE DATA REQUIRED TO CONTINUE REAL-TIME 
OPERATIONS) 

• USE FLIGHT CREW FOR REAL-TIME HOUSEKEEPING OPERATIONS OF EXPERIMENTS 
(PROVIDE GROUND BACKUP CAPABILITY) 

• MAINTAIN FLEXIBILITY INTHE MODE OF OPERATIONS (ONBOARD VS GROUND) 
DEPENDING UPON MISSION/PAYLOAD TYPE 

FOLLOW ON STUDIES: 

•EVALUATE THESE APPROACHES FOR DOWNSTREAM MISSIONS 

• GROUP PAYLOADS TO OPTIMIZE THE UTILIZATION OF FLI GHT CREW 


Figure 1-4-2. Onboard vs Ground Beal-Time Mission Operations Recommendations 
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PART II 

GROUND DATA MANAGEMENT ANALYSIS 
(TASK 2. 2B) 



PART II - SUMMARY 

The high quantity of data expected from the Spacelab payloads will create a 
significant problem for both the real-time data processing required to support 
mission operations and the non-time-critical data processing needed for 
experiment data analysis. The purpose of this study was to better understand 
the ground data management problem and to recommend potential solutions. 

Initially, an information search was performed to determine what studies had 
been conducted and what plans established within the payload and Space 
Transportation System (STS) communities relative to payload ground data 
management. The results of this search indicated that a significant amount 
of work had already been accomplished in this area. Appendix A provides a 

t 

list of study reports and other related documents accumulated daring the 
information search. 

One of the most significant findings of the information search was a lack of 
definitive payload ground data processing requirements. It was recognized 
that detail requirements could not be produced until late in a payload's develop- 
ment phase; however, general requirements could be predicted and were 
necessary to allow for tbe long lead times required for development of the 
complex ground dath processing systems. Therefore, in Phase 2 of this task, 
efforts were concentrated on the development of the generalized payload ground 
data requirements, particularly those that tended to drive ground data system 
design. The reports collected during the information search were reviewed 
to extract applicable requirement type data. Various personnel within the 
payload community were surveyed to supplement this information. Effort was 
concentrated on the payloads and types of instruments anticipated to fly in the 
mid-1980's as these payloads are more demanding on the ground data proc- 
essing systems. c 



The more significant ground data requirements of the future which exceed 
the data processing capabilities currently planned for the early Spacelab 
missions are summarized below: 

• Imaging instruments will generate digital data rates far in excess 
(potentially in excess of 1, 000 MBPS) of current recording, 
transmission, and processing capabilities. 

• Real-time image processing will be required to allow interactive 
control of the image producing instruments. (It is anticipated that 

a 1-MBPS real-time image processing capability will be acceptable, ) 

• Simultaneous transmission of video and high- rate digital scientific 
data (much greater than the 2-MPBS capability currently planned) 
will be required. 

• Data quantities (potentially in excess of 1 x 10 ^ bits/day) will far 
exceed the current capabilities to record and process data within a 

. reasonable period. 

During the final phase of this task, various data processing concepts were 
evaluated to determine which concepts could most effectively satisfy future 
requirements. The total data processing system was considered, including 
onboard processing, air and ground transmission systems, real-time data 
processing, and the non-time-critical postflight data processing. One of 
these advanced end-to-end concepts is depicted in Figure II- 1. 

The major conclusions from this analysis was that high data quantities from 
a few Spacelab payloads are the most significant parameters that drive ground 
data system design. Thus, recommendations range from means to reduce 
these data quantities (e. g. / onboard compression and selective processing) 
to large data processing computing complexes designed with growth potential 
as a key requirement. It is recommended that integrated payload data 
requirements be developed and that guidelines related to integrated payload 
data management capabilities and limitations be prepared for the payload 
community for both real-time and postflight data processing. NASA should 
promote the future use of payload microcomputers (plus memories) rather 
than the use of an onboard centralized computer for scientific data processing. 
Complete payload data autonomy should be the goal. 
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Section 1 
INTRODUCTION 

Spacelab experiment operations are expected to generate a great deal of data 
which will be transmitted to the ground via the Tracking and Data Relay 
Satellite (TDRS). These data will be digital data up to 50 MBPS and will 
contain real-time data multiplexed with previously recorded data. In addi- 
tion, analog and video data will also be transmitted to the ground via TDRS. 
The proper approach to the ground data management problem must be 
established in order to most cost effectively support real-time operations as 
well as postflight analyses. 

1.1 PURPOSE 

The purpose of this task was to conduct an analysis of the Spacelab experiment 
operations ground data management problem and to establish the most effec- 
tive approach for ground data processing and distribution to support real-time 
operations as well as postflight analyses. 

1.2 SCOPE 

This task was conducted during the period from July 1976 through March 1977. 
During the early study phase, efforts were concentrated on determining what 
plans had already been established and what studies had been conducted rela- 
tive to the ground data handling problem. The subsequent study tasks relied 
heavily on the data gathered during this initial phase. 

It was determined early in the study that the payloads which would tend to 
drive the ground data processing system design were those with image- 
producing instruments transmitting their data via the digital data systems. 
Study efforts were then concentrated on the processing of data from these 
instruments. An integrated set of payload ground data requirements was 
developed which was representative of anticipated user needs. These 
requirements were general in nature and concentrated on those areas which 
tended to drive ground data systems design. 
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The final study phase to establish effective approaches to payload ground 
data management was limited in scope to conceptual definition only. Several 
existing concepts were evaluated and some new concepts were introduced. 

1.3 MAJOR GROUND RULES AND ASSUMPTIONS 
Major ground rules and assumptions are as follows: 

A. Emphasis will be concentrated on the Spacelab missions and payloads 
of the raid- 1980's and subsequent time frame. 

B. Only Spacelab experiment data transmitted via the TDRS will be 
addressed. 

C. No major deviations from currently planned data handling systems 
will be made during the new concept development (e. g. , maintain 
high rate multiplexer, Ku-band signal processor, TDRSS). 
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Section 2 

APPROACH 

The general approach followed for this task is outlined in Figure H-2-1. 



• EXISTING PLANS 
AND STUDIES 

• FLIGHT AND GROUND 
DATA SYSTEMS 
DEFINITION 


Figure 11-2-1. Study Flow 


• DEVELOP PAYLOAD 
DISCIPLINE DATA 
REQUIREMENTS 

• IDENTIFY REQUIRE- 
MENTS WHICH DRIVE 
GROUND SYSTEM DESIGN 

• COMPARE REQUIREMENTS 
WITH EXISTING PLANS 


• ONBOARD DATA 
PROCESSING 

• AIR AND GROUND 
TRANSMISSIONS 
SYSTEMS 

• GROUND REAL-TIME 
PROCESSING 

• GROUND POSTFLIGHT 
PROCESSING 


2. 1 PHASE 1 


An information search was performed to determine what studies had been 
conducted and what plans established within the STS community relative to 
real-time and postflight ground data management. These findings were 
integrated to determine where gaps and potential problems existed and to 
develop follow-on tasks to concentrate on these areas. 


2.2 PHASE 2 

One of the most significant findings of the Phase 1 information search was a 
lack of definitive payload ground data processing requirements. It was 
recognized that detail requirements could not be produced until late in a 
payload's development phase. However, general requirements could be 
predicted and were necessary to allow for the long lead times required for 
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development of the complex ground data processing systems. Phase 2 
concentrated on the development of the generalized payload ground data 
requirements . 


A definition of the desired requirements data needed was developed and 
checklists and tables to aid in the collection of this data were made. The 
various payload disciplines were evaluated to deter mine which had the 
greatest demands for ground data processing. A priority listing was 
established and the more demanding payload disciplines were given greater 
attention. 

The information collected during Phase 1 was searched and all applicable 
requirements data were extracted. Where data were not available, personal 
contacts were made within the payload community to provide the necessary 
data. 

After the generalized ground data requirements from each payload discipline 
were collected, they were integrated to identify those requirements which 
would tend to drive ground data system design. These requirements were 
compared with existing ground data processing plans and the incompatibilities 
were identified. 

2.3 PHASE 3 

Using the requirements established in Phase 2, various data processing 
concepts were evaluated to determine which concepts would most effectively 
satisfy the requirements. The total data processing system was considered, 
including onboard processing, air and ground transmission systems, real- 
time data processing, and the non-time- critical postflight data processing. 



Section 3 
STUDY RESULTS 


3. 1 INFORMATION SEARCH 

The Spacelab payload ground data management problem has been of concern 
to the NASA for several years. Significant effort has already been expended 
among the various NASA centers and their contractors to address specific 
segments of the problem. The purpose of the information search was to 
gather the documented reports of the various studies already conducted, 
integrate and evaluate their findings, and determine where additional efforts 
were needed to solve the overall ground data management problem. 

3. 1. 1 Data Sources 

GSFC, JSC, and MSFC have been the prime NASA centers concerned with 
ground data management of Spacelab payload data. Each of these centers 
was visited, key personnel were interviewed, and available reports were 
collected. This activity was coordinated through the appropriate STS Payload 
Requirements and Analysis Group (SPRAG) members. The MDC personnel 
located at JSC provided significant support in the collection of data at that 
location. In addition, other NASA centers and suppox-t contractors were 
contacted by telephone to request reports related to the ground data manage- 
ment problem. 

3.1.2 Information Located 

Appendix A provides a listing of all material located either directly related 
to or significantly contributory to Spacelab payload ground data management, 

3. 1. 3 Data Integration 

Documented results of the various studies and NASA planning documents were 
reviewed and significant data related to Spacelab experiment ground data 
management were extracted. These data were then integrated with infor- 
mation gathered through discussions with NASA pei'sonnel. For ease of 
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reference, the data were gathered and summarized on a 
sheet. The work sheet and reference documents reviewed 


questions remain unanswered. It became ot 
experiment data generation and data transm 
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Spacelab experiments are lacking a total integrated set of operational require- 
ments. As a result, post flight and real-time ground data processing 
requirements have not been suffiently defined for ground hardware system 
definition. Some of the general requirements of significance included a strong 
desire by the payload community to monitor, and in some cases exercise, 
ground commands to the payloads from remote facilities where their payload 
development activities have been concentrated, in addition, some experi- 
menters (e. g. , solar physics) have expressed a need for ground monitoring 
of high-rate image data in real or near real time to allow for reprogramming 
of payload mission operations. 

Several studies resulted in rough order of magnitude (ROM) cost estimates for 
ground data handling systems (Table II-3-1). Since actual payload user 
requirements had not been defined, requirements were parameterized in 
terms of mission use, turnaround time, data volume, and system throughput 
data rate. A set of design points was selected which spanned the possible 
system performance requirements explaining the wide range in ROM costs. 

The ROM costs noted are, therefore, a function of possible user requirements. 


Table II -3-1 

ROM COST ESTIMATES FOR SELECTED PAYLOAD 
GROUND DATA HANDLING SYSTEMS 


Sensor /Payload 

ROM Facility 
Cost* 

ROM Operating 
Cost* per Year 

Interferometer Spectrometer/ 
Atmospheric and Space Physics 
(Ref 25) 

1. 8 to 8. 1 

2.6 

Ultraviolet Sp.ectroheliometer / 
Solar Physics 
(Ref 29) 

10. 5 to 65. 4 

1.1 to 17.0 

Synthetic Aperture Radar /Earth 
and Ocean Physics 
(Ref 6) 

24 to 1 1 1 

3.2 to 34. 6 

Earth Viewing Remote Sensing 
Using Multispectral Scanners /Earth 
Resources 
(Ref 34) 

^Cost in millions of dollars (1975 to 1976). 

36. 1 to 107. 2 

N/A 
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In each, case, a sensor was selected from a payload discipline for evaluation 
which was considered to drive the overall cost. ROM cost numbers were 
extracted from the referenced documents. 

The dominating conclusion from the studies reviewed is that the high data 
quantities from a few Spacelab payloads is the most significant parameter 
driving ground data system design. Proposals range from means to reduce 
data quantities (e. g. , onboard compression and selective processing) to large 
ground data processing complexes with high associated costs designed with 
growth potential as a key requirement. 

3. 2 PAYLOAD DATA REQUIREMENTS 

One of the more significant findings of the information search was a lack of 
definition of payload ground data requirements. It was recognized that 
development of detailed requirements is often impossible until late in the 
payload development stage when measurement programs are defined and 
payload operating plans established. However, general requirements can be 
anticipated and are necessary to allow for conceptual design and long-range 
planning of the ground data processing facilities. The reports collected 
during the information search were researched to extract applicable require- 
ment data. Various personnel within the payload community were surveyed 
to supplement this information. Effort was concentrated on the payloads and 
types of instruments anticipated to fly in the mid-1980’s. 

A questionnaire was formulated (see Appendix B) to be used as a guide for 
data gathering from the existing documents and from the personal interviews. 
This questionnaire was not distributed to the payload community for them to 
complete as this approach had been previously attempted by others and was 
unsuccessful. It was used as a checklist during documentation search and 
personal interviews. In conjunction with the questionnaire, a table was 
constructed to organize the requirements data (see Appendix C), 

3. 2. 1 Documentation Search 

An automatic search of the NASA Payload Planning Data Bank (PPDB) was 
performed (a sample computer search is shown in Figure lT-3-2) to deter- 
mine which payloads in particular and which scientific disciplines in general 
generated the greatest digital data rates and quantities. Figure II -3 -3 
summarizes the data from this search. 
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Figure 1 1-3-2. PPDB Sort to Support Payload Selection 


.!•! 

u 


* l 
£J 


v l 


SOLAR PHYSICS 


PAYLOAD 


SO-18S SOLAR ATMOSPHERIC WAVE PROPAGATION 
S0-19S PHYSICS OF FLARING BRIGHT POINTS 
SO-15S .SOLAR ACTIVITY EARLY PAYLOAD 


ASTRONOMY 
AS-50S 
AS-31S 
AS-32S 
AS-54S 
AS-04S 


COMBINED UVAND Ifi TELESCOPES 


UV OPTICAL TELESCOPE 

HIGH ENERGY ASTROPHYSICS 
HE-23S GAMMA RAY SURVEY 

COMMUNICATIONS AND NAVIGATION 
CN-18S ADAPTIVE D IGITAL VIDEO COMPRESSION SYSTEM 


PRODUCING INSTRUMENTS (SPECTROMETERS, PHOTOHELIOGRAPHS, 
INTERFEROMETERS, MULTI SPECTRAL SCANNERS, I MAG ING RADARS) 


MAX DOWNLINK 
DIGITAL RATE 
(MBPS) 

DATA 

VOLUME 

(MB/DAY) 

23.0 

2.0x1012 

21.0 

9.7 X 10U 

5.7 

2.6X1011 

10.5 

4.6x1010 

10.3 

5.6x109 

10.3 

5.7x109 

10.2 

2.0x1010 

10.0 

3.1 x 109 

10.0 

8. 6 x 10 n 

10.0 

3.6x1010 

IVEN BY PAYLOADS WITH IMAGi 


28147 


Figure H-3-3. High-Data-Rate Payloads from PPDB Search 
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The documents gathered during the information search were reviewed and 
data requirements extracted. A summary of estimated scientific data 
characteristics is presented in Figure II- 3-4. Figure H-3-5 lists the pri- 
mary references used in the search. The housekeeping data characteristics 
were all very low in data rate and appear compatible with current plans for 
processing this data, 

Appendix C provides the detailed results of the documentation search in table 
form. The table is organized by subject matter responsive to the require- 
ments questionnaire discussed earlier. 

3. 2 . 2 Personal Interviews 

Various personnel throughout the payload community were interviewed to 
determine their ideas and opinions as to what future payload ground data 
requirements would be. The more significant findings of this survey are 
summarized below: 

• The payload community in general has a strong payload operator 
concept. In many cases they believe each instrument should 

have full parallel control from onboard and from the ground. They 
would prefer to have ground control from their home site for 
reasons of (1) availability of support equipment and software, 

(2) availability of support personnel and data, and (3) time and 
travel budget constraints. This concept results in heavy require- 
ments for real-time ground data transmission and processing 
systems. 

• Historically, much data that has been transmitted to the ground 
and processed has been useless to the scientist, because of poor 
quality or lack of scientific value. There are many methods to 
reduce production and transmission of this data which should be 
explored. For example, development of a cloud analyzer could be 
beneficial to several payload disciplines. Dependent of the experi- 
ment objectives, there are cases when data should be generated 
only when clouds are absent or when clouds are present. Develop- 
ment of such a device may be too expensive for the individual 
payload but may prove cost effective when used for several payloads 
with the resultant reduced ground data handling and processing 
costs. ■ 
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Figure 11-34. Estimated Scientific Data Characteristics 


DISCIPLINE 

REFERENCE 

NO. 

28178 

REFERENCE 

ASTRONOMY 

1 

IBM, "GROUND SUPPORT REQUIREMENTS FOR SELECTED 
SHUTTLE PAYLOADS," AUGUST 1975 

HIGH ENERGY ASTROPHYSICS 

1 

— 

SOLAR PHYSICS 

2 

IBM, "SPACELAB USER INTERACTION STUDY, PHASE 2 REVIEW " 
MAY 1975 


3 

BALL BROa, "SHUTTLE ERA GROUND DATA PROCESSING 
PARAMETRIC REQUIREMENTS FOR THE DISCIPLINE OF SOLAR 
PHYSICS," AUGUST 1975 

ATMOSPHERIC, MAGNETOSPHER1C 
AND PLASMAS IN SPACE (AMPSJ 

4 

MARTIN MARIETTA, "ATMOSPHERIC, MAGNETOSPHERE AND 
PLASMAS IN SPACE (AMPS) SPACELAB PAYLOAD DEFINITION 
STULrv " NOVEMBER 1976 


EARTH OBSERVATIONS 5 GENERAL ELECTRIC, "EARTH VIEWING APPLICATIONS 

LABORATORY (EVAL) CONCEPT DEFINITIONS/PARTIAL 
SPACELAB PAYLOAD TECHNICAL REPORT," SEPTEMBER 1970 

2 

EARTH AND OCEAN PHYSICS 6 IBM, "SYNTHETIC APERATURE RADAR (SAR) GROUND DATA 

PROCESSING FACILITY DEFINITION STUDY," JANUARY 1976 

1 

SPACE PROCESSING APPLICATIONS 7 NASA-MSFC, "SPACELAB DESIGN REFERENCE MISSION 

ANALYSIS, VO L. IV, MISSION C. . .SPACE PROCESSING 
APPLICATIONS," APRIL 1975 


SPACE TECHNOLOGY B AERONUTRON1C FORD, "LANGLEY APPLICATION EXPERIMENTS 

DATA MANAGEMENT SYSTEM STUDY-FINAL REPORT," 
DECEMBER 1975 


Figure 1 1-3-5. Primary References used for Data Requirements Analysis 
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® The long-term archiving of unprocessed (raw) data was not believed 
to be cost effective. Past usage of this data has been extremely 
low. It was suggested that one to three months should be adequate 
for archiving of this raw data by NASA. 

• It was recommended that all scientific data be available at the 
Payload Operations Control Center (POCC) for potential real-time 
or near real-time monitoring in support of mission operations. 
Image processing will be required at the POCC to allow interactive 
control of the imaging instruments. It was believed that a 1 -MBPS 
real-time image processing capability would be satisfactory. 

• A requirement will exist for simultaneous downlinking of TV and 
high -rate (greater than 2 MBPS) digital data. The current STS 
wide-band data transmission systems preclude this simultaneous 
transmission. 

• Up to 10 manually switchable inputs to the Spacelab video network 
will be required to accommodate 10 pointing instruments which 
could fly on a five -pallet mission. 

• A text and graphics uplink capability of 1 MBPS should be provided 
for star charts, new observing plans, etc. 

• Onboard data storage capable of storing high rate data (much 
greater than 50 MBPS) for relatively short periods and for 
subsequent playback via TDRS at slower rates should be provided. 

© Central data analysis facilities make sense for the large users 

with similar image -producing instruments; however, concern was 
expressed over potential saturation by a few instruments. 

• Onboard centralized computer support is not recommended due to 
complexity and cost of software integration and verification. Use 
of microcomputers with individual instruments is preferable. 
Complete data autonomy should be a goal for each payload. 

• As instrument design improves and as scientific objectives become 
more demanding, data rates will increase. Figure II-3 -6 depicts 
a typical example of how a facility class instrument planned for 
flight in the mid- 1980's and a scientist's desire to evaluate solar 
flare associated shockwaves at a velocity of 1, 000 km/sec could 
result in a data rate of 1, 800 MBPS. 
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PARAMETERS 
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CAPABILITY 
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0.1 ARC SEC 
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< 1J IF INFORMATION REQUIRING SIMULTANEOUS OBSERVATIONS IN DIFFERENT WAVE 

LENGTHS AND POLARIZATIONS IS DESIRED, THE NUMBER IS CORRESPONDINGLY HIGHER. 

Figure 11-3-6- Solar Physics 1 -Meter Class Helioscope Data Rate Definition 


3. 3 SYSTEM CONCEPTS 


3. 3. 1 Current Plans 

The Spacelab Payload Data Network is seen to primarily consist of the 
Orbiter and TDRSS data link, the terrestrial telecommunications system 
between the TDRSS ground terminal and NAS COM terminal systems at GSFG 
ind JSC, and a return data link via a domestic satellite (DOMSAT) from the 
TDRSS ground terminal to JSC and GSFC, as shown on Figure II-3-7. In 
addition, low-rate payload data integrated into the Orbiter's bit stream may 
be obtained in a backup mode via the Space Flight Tracking and Data Network 
(STDN) consisting of stations in Fairbanks, Alaska; Goldstone, California; 
Rosman, North Carolina; Orroral, Australia; Madrid, Spain; and the launch 
control stations at Bermuda and Merritt Island, Florida- Using the Merritt 
Island station and pad facilities, it will also be possible to transmit payload 
data to the network via the TDRS for checkout purposes. 


Real and non-real time data will be provided to users at JSC and the tape 
mailing system is indicated as continuing in use at GSFC, In addition, it has 
been projected that users may wish to employ their own DOMSAT terminals 
for direct high-rate data reception although no firm plans have been developed. 
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Figure 11-3-7. Spacelab Payload Data Network 


3. 3. 1. 1 Onboard Systems 

Payload data will interface with the Spacelab and Orbiter systems via remote 
acquisition units (RAUs), the high-rate multiplexer, and an input to the 
Orbiter's Ku-band signal processor (see Figure II-3-8). The data processing 
assembly; consisting of the computer, input/output (I/O)., main memory unit 
(not shown), data display units (not shown); and the RAUs perform the 
functions of command processing and distribution, data acquisition, data 
processing and transmission, and data display. 


The RAUs constitute the low -rate payload data interface. The maximum 
capability of this interface, as indicated on the right-hand side of Figure II-3-8, 
is compatible with the data bus average simplex rate of 600 kBPS and maximum 
transfer rate of 1 MBPS in the burst mode. The figures shown for command 
and data acquisitions were obtained from the CDMS Specification, Document 
No. SS-ER-0004, and are believed to be maximum individual rates with pro- 
gramming apportioning the bus capability as necessary for actual operation. 


The average output rate of the system to the Orbiter pulse code modulation 
(PCM) units for experiment ground control is 64 kBPS as indicated by the 
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Figure 11-3-8. Onboard Systems Spacelab Payload Data Flow 

upper left-hand capability data. Actual maximum transfer rate is 1 MBPS in 
the burst mode. The data is integrated with Orbiter data to comprise a 
128-kBPS data stream which may be transmitted via S- or Ku -band systems. 
In addition, the capability for command uplink and Orbiter state vector update, 
which would include position and velocity vectors, mission elapsed time 
(MET), Greenwich Mean Time (GMT), and attitude as well as target update 
(position, velocity, GMT), via the multiplexer /demultiplexer interface are 
shown. 

The high-rate multiplexer (HUM), shown at the bottom of Figure II-3-8 
constitutes the interface for high-rate data. It also includes a data input from 
the I/O at 1 MBPS which is essentially the data bus rate. Outputs interface 
with the High Data Rate Recorder (HDRR), payload recorder, and the 
Orbiter 1 s Ku -band signal processor. Interface information was obtained 
from The System Concept and the System Requirements for the Spacelab High 
Data Rate Multiplexer /Demultiplexer, Document No. SLP/2107 dated 
May 11, 1976 (Reference 37). 
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Figure II -3 -9 shows the detailed functional data flow of the HUM interface 
between the Spacelab experiments and the Ku-band signal processor. The 
HRM can operate in seven distinct modes for downlinking the Spacelab data 
(see Reference 37): 

A. Multiplexed data in real-time transmission on one of the three 
Ku-band signal processor (KUSP) inputs. 

B. Multiplexed data recorded on one of the two tape recorders. 

C. Combined tape recorder dump and real-time transmission of 
input data. 

D. Recorder direct data dump and multiplexed input data on separate 
KUSP inputs. 

E. Direct access to the 50 MBPS input and the multiplexed input data 
transmitted on separate KUSP inputs or recorded. 

F. Direct access recorded, data and multiplexed input data trans- 
mitted on separate KUSP inputs, 

G. Multiplexed input data or direct access input data transmitted and 
recorded (on the high data rate recorder) in parallel. 

The characteristics for the two onboard tape recorders are listed in 
Figure II-3-10. The two key characteristics to make note of are (1) data 
rate input and (2) data storage capacity which is a maximum for the HDRR, 
32 MPBS and 3. 6 x 10^ bits, respectively. 

The KUSPs functional flow charts are illustrated in Figure II-3-11 which 
indicates the switching logic available to downlink the Spacelab '.s experiment 
data. The KUSP may operate in two different modes as illustrated in the 
Table 31-3-2. 


3.3. 1.2 TDRSS 

It is the intention of the TDRSS to be effectively transparent to the Spacelab 1 s 
data network. The TDRS acts as a bent-pipe to the Ku-band return link and 
relays the data to a ground station located at White Sands, New Mexico. The 
ground station provides the bit synchronization for the return link and decodes 
the TDRS encoded data. This data is then retransmitted to JSC and GSFC 
via a NASCOM land line (at 1. 544 MBPS) or a proposed DOMSAT (at a data 
rate comparable to the TDRSS return data link). A TDRS ground station 
functional flow block diagram is shown in Figure H-3-12. 
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Figure 11-3-11. Functional Flow of the Ku-Band Signal Processor 
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Figure il-3-12- TDRSS Ground Station Functional Flow 
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3. 3. 1. 3 JSC Ground Systems 

Real-time ground support of Spacelab payload operations is currently planned 
to be supported from a centralized POCC located at JSC. 

JSC plans to acquire the wide -band scientific data from the TDRS ground 
station via a DOMSAT. The operational data stream (and low-rate scientific 
data) will be received via land line capable of 1. 544-MBPS data transmission. 
The operational data will include the voice loops and will be processed and 
available to the POCC in real time. It will be possible to display 500 param- 
eters of the operational d?ta on cathode ray tubes (CRTs) and/or strip charts. 
This data will be available for immediate recall for a 6 -hour period. 

The wide-band scientific data will be demultiplexed and up to 4 channels of 
data extracted. Processing data from three of these channels will be limited 
to 256 kBPS each and the fourth channel limited to 2 MBPS. Five hundred 
parameters from each of these channels can be displayed (CRT capability will 
limit total display to 800 parameters at any instant). Data scheduled for 
display is available for immediate recall for a 6 -hour period. Other data on 
these channels will be recorded and can be made available within 4 hours of 
any 6 -hour period. 





Television data which is compatible with the Orbiter system can be displayed. 
Current plans do not account for processing of payload analog data or for 
image processing of digital data. Text and graphics uplink capability will be 
limited to 8 kBPS for the eax*ly Shuttle flights and upgraded to 128 kBPS 
effective with Shuttle flight 17. 

The JSC POCC will provide standard unit conversion, limit sensing, and 
simple logic -arithmetic computations. Special online and offline payload 
computation support can be provided on a case-by-case basis. 

The following information on JSC ground data processing was extracted from 
Reference 24. 

Mission Control Center (MCC) and TDRSS Interface 

The MCC and TDRSS interface is comprised of voice, telemetry, video, and 
command data. The voice interface will include single or dual air-to-ground 
and ground-to-air duplex voice links between the Orbiter and MCC, and also 
postpass transmission to MCC of all recorded voice tapes. The telemetry 
interface will include real-time landline transmission to the MCC of up to 
1 MBPS of payload data. Transmission to MCC of multi -megabit scientific 
data will be provided by a TDRSS /DOMSAT /MCC interface. The video inter- 
face at MCC will accommodate both real-time and postpass video data. 

The TDRSS /DOMSAT /MCC interface will be identical to the TDRSS and MCC 
interface and will allow for a throughput (including the multi-megabit data 
stream) of the entire Orbiter and payload downlink streams, as received by 
the TDRSS ground station. 

MCC and POCC Interface 

The exact configuration of the circuits and interface characteristics between 
the MCC and POCC are not determined at this time. However, the POCC 
must have nearly unrestricted access to the data at MCC. The interface will 
be comprised of voice, telemetry, and video data. The voice data will 
consist of two full-duplex voice channels for payload support. The telemetry 
data interface will be comprised of housekeeping low-rate sensor data, along 
with a high-rate scientific data link (currently one channel of 2 MBPS and 
three channels of 256 kBPS of data). The video interface will consist of a 
one-way transfer from the MCC to the POCC of Orbiter video data. 
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3. 3. 1. 4 GSFC Ground Systems 

GSFC is responsible for the Spacelab payload non-time -critical data pro- 
cessing, Processing functions currently planned at GSFC for the early 
Spacelab missions are (1) data capture (record) of all payload data telemetered 

on the wideband link and (E) verify, format, and forward data to experi- 
menter's facilities for reduction, analysis, and archiving. The full pro- 
cessing system will be sized to process and deliver all data within 30 days. 
Firm plans for later Spacelab missions have not yet been made. More 
detailed information on GSFC ground data processing can be found in 
Reference 24. 


3. 3. E Incompatibilities of Current Plans vs Future Ground Data 
Requir ements 

It is clear from the data requirements itemized in Subsection 3. 2 and the 
corresponding ground data processing capabilities listed in Subsection 3,3. 1, 
that new data handling techniques will be required to accommodate the 
Spacelab experiments during the 1985-1990 time frame. Reducing the instru- 
ment data rates arbitrarily to match current ground processing capabilities 
will cause a significant reduction in the instrument's performance. This is 
illustrated in Figure II-3-13 for the synthetic aperature radar (SAR) sensor. 
The desired ground resolution for the SAR sensor is equal to or less than 
100 meters which relates to approximately 50 MBPS for this example. A 
further reduction in data rate would produce a disproportionate degradation 
in resolution. 


The range of expected data volumes and data rates for four key image sensors 
is shown in Figure II-3-14. This plot illustrates the combined data handling 
requirements for these instruments. Also, the area representing the 
current ground data handling capabilities was signified by cross-hatching the 
appropriate values on the same plot. The data volume limitation was deter- 
mined by a survey of the digital storage technology performed during this 
study (see Subsection 3, 3. 3). Again it is clear that more advanced data 
handling techniques will be required to pi*operly process the data from these 
instruments. 

The more significant ground data requirements of the future which exceed 
the data processing capabilities currently planned for the early Spacelab 
mission are summarized below: 
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SWATH WIDTH CW) PULSE REPETITION FREQ (PRF) 
DTART ° RESOLUTION (5) X PRESUME I NG FACTOR (n) 
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BASELINE DESIGN GUIDE LINES: 
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Figure 11-3-13. Synthetic Aperture Radar Data Rate vs Resolution 
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Figure 11-3-14. Estimated Sensors Digital Data Output Characteristics 


O/VjVEri.1. DOUGLAS 


OxC 


164 









• Imaging instruments will generate digital data rates far in excess 
(potentially 1, 000 MBPS) of current recording, transmission, 
and processing capabilities, 

• Real-time image processing will be required to allow interactive 
control of the image producing instruments, (It is anticipated 
that a 1 -MBPS real-time image processing capability will be 
acceptable. ) 

e Simultaneous transmission of TV and high-rate scientific data 
(much greater than the 2 -MBPS capability currently planned) 
will be required 

• Data quantities (potentially in excess of 1 x 10 1 bits /day) will 
far exceed the current capabilities to record and process data 
within a reasonable period of time. 

3,3.3 Proposed New Concepts 

A perspective flow diagram of a conceptual Spacelab data link is shown in 
Figure H-3-15. The major elements in the end-to-end data link are (1) the 
onboard systems (Shuttle), (2) ground systems providing real-time pro- 
cessing (JSC), and (3) ground systems providing data processing that is not 
time critical (GSFC). 


The functions proposed to be performed onboard the Shuttle are data storage, 
data compression, interactive control and display with both hard and soft- 
copy capability and data transmission. The functions recommended for the 
real-time processing site are quick -look analysis, diagnostics, and 
temporary storage. The non -time -critical processing functions that are 
recommended are image processing (limited), data base processing, creation 
of instrument data files, and provision of a complete data interface with the 
user. 


3, 3. 3. 1 Digital State -of-the -Art Storage Survey (References 43 to 56) 

Figure II-3-16 presents a table summarizing the results of a brief survey 
made of available and proposed (1980's) digital storage devices. It will be 
noted that we have made no distinctions between airborne and ground equip- 
ment, An analysis that includes such distinctions would be a useful follow-on 
effort. 
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Figure U-3-15. Spacelab Data Downlink Flow Capabilities 
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DIGITAL DATA 
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CAPACITY 

(BITS) 

BIT RATE 
(BPS) 

ACCESS TIME 
(MICROSECONDS) 

COST PER BIT 
(CENTS/BITI 

CAPACITY 

(BITS) 
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APPLICATION 

1. MAGNETIC CORE 

7x10 3 TO 

BxlO 7 

< 1 MBPS 

0.15 TO ID 

-0.50 

10* 

1 MBPS 

MAINFRAME MEMORIES 
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10 12 

2D MBPS 
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IMAGE STORAGE DEVICES 
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Figure 11-3-16. Table of Digital Storage Technology 
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Magnetic -core storage is widely used for the main storage and is directly 
accessible by the computer's processing unit. The data is stored in a spatial 
array of elements; in this case, each element can store a single bit and 
physically consists of a tiny donut-shaped object, which is the magnetic core. 
Some of the techniques of storage organization used with core storage 
(e. g, , 2D, 3D, and 2-1 /2D schemes) are also applicable to other technologies, 
especially magnetic films. As a rough indication of speed and capacity avail- 
able in the year 1974, we took the Ampex ECM (Reference 43), as an example, 
with controller modules of 10' bits: 

« Read /write cyle - 1 MBPS 

® Capacity - 10^ bits 

It is estimated that the magnetic core technology will not advance significantly. 

There is much written in the literature on the various types of magnetic tape 
systems (References 43, 47, and 55) and the values in the tables are reason- 
able estimates of both airborne and ground devices. Access to these 
machines takes place in a sequential fashion. Data are recorded as magnetic 
spots oil typically 9 to 28 positions across the width of the tape. Such a set 
of nine positions may, for example, represent eight information bits and one 
bit for parity checking. Corresponding to each bit position is a read and 
write head used for recording or sensing information on the tape. Thus data 
are retrieved or sent one bit at a time (nine bits in parallel) to the recording 
heads. When the tape is at rest, recording or reading can start only when 
the tape is accelerated to, or near, maximum speed. This delay is called 
start time; it is on the order of 5 msec. An example of a high speed capacity 
system is the Ampex Terabit memory which has an input and output bit rate 
of 6 MBPS and a capacity of 3 x 10^ bits/3800-ft reel. Further advances in 
this technology is also expected to be limited.. 


Magnetic disk is available in a variety of arrangements. One scheme uses 
the recording surfaces on rotating disks; all disks rotate together at a fixed 
speed — the y arc not stopped or started for access purposes. Read and write 
heads are mounted in a comb arrangement and each comb has one head for 
each recording surface, Data are typically stored serially by bit along each 
of the multiple concentric circles (i. e. , tracks) of each disk. Since all heads 
are positioned together, a single comb position makes a set of tracks avail- 
able. This set of iracks is referred to as a cylinder. Since head -positioning 
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or seek time requires the longest delay for random access, the capacity of 
a cylinder is important* In addition to seek time, random access also 
requires a rotational delay which is approximately in the 10 -msec range. 

For high-speed capacity machines, the input and output bit rates range from 
2. 7 to 6, 5 MBPS and have capacities of approximately 10^ bits (reference 43). 
Developmental disk devices have increased capacities of up to 10 ^ bits. 


Semiconductors, at the present time, do not serve the mass memory market; 
however, they do provide a solution for temporary storage (e. g. , buffers). 
Metal oxide semiconductor (MOS) and bipolar transistors are fabricated as 
monolithic integrated circuits, which is defined as an inseparable assembly 
of circuit elements in a single structure which cannot be divided without 
permanently destroying its electronic function. 


The MOS transistor is an active semiconductor device in which a conducting 
channel is induced in the region between two electrodes (source and drain) 
by a voltage applied to an insulated electrode (gate) on the surface of the 
semiconducting material (chip). Bipolar devices such as transistor -transister 
logic (TTL), emitter -coupled logic (ECL), etc. , use the conventional p-n 
junction effect to establish integrated circuit (IC) gates which can act as 
memory circuits. The junctions are formed by application of alternating 
steps of various masks and diffusion depths to a semiconductor material. 
Charge -coupled devices (CCDs) are similar to the MOS shift-register devices 
but depend on the controlled movement of electrical charges rather than on 
transistor -like circuits. CCDs are more compact, simpler, and lower in 
cost than integrated circuit devices. The primary application of CCDs is 
high-density, low-cost storage. 


The values used in this survey for semiconductor memories are the result of 
surveying published documents (References 43, 46, 47, 50, 51, 52, and 56). 
The advantage of these devices are their high packing densities. The results 
indicate that semiconductor memories will be useful as data buffers, low- 
capacity main memories for microcomputers, and caches for frequently used 
data. 


Magnetic bubbles, with the same logic design as shift registers, are' developed 
in a single -crystal layer of a ferro- or ferrimagnetic material and data can 
be made to move along paths on the surface. This technique offers low-cost 


MCOONNGUL 




168 


plus high density (i. e, , Reference 43 stipulates 10^ bits/in. 2 forecast), but 
is considerably slower in access time than the semiconductor technologies. 
This device may be a likely candidate for spaceborne recorders because of 
their high reliability and increased storage density with corresponding 
decrease in weight and power. 

Optical recording and readout memory systems consist of a beam source 
(laser), beam control device, memory medium, beam deflector, focusing 
and pivoting medium, focusing and pivoting optics, and a light detector. The 
high packing density potential of optical memories of more than 10® bit/in. ^ 
reduces the size of a TO bit memory to 10,000 in. of recording surface 
(Reference 43). However, these capabilities have not been realized because 
of the following problems. 

A. Development of a suitable, nonvolatile, erasable, optical 
storage medium. 

B. Development of high-speed, high-repetition-rate, low-cost 
digital deflectors which can address a large number of 
resolution elements. 

C. The addressability of a field of 10® bits presents a difficult 
problem due to diffraction, depth of field, depth of focus, etc. 


Electron beam devices seem to be far more attractive as a recording device 
than laser beams (References 54). Electron beam recording utilizes a spot 
size of the order of 10^ fits* which produces densities of 10^ bits /in. 2. The 
electrical signal to be recorded modulates the intensity of an electron beam 
which is directed at a silver halide recording medium (other mediums are 
being used, e. g. , MOS SiO^/Si interface). In the readout process, the same 

scanning pattern is used as that used to record. "When the beam, acting as a 
constant current source, strikes the film, a spot of light ( equal in size to the 
cross section of the beam) is generated by a scintillator coating over the 
emulsion. The intensity of the light, when viewed through the film is modu- 
lated as the spot is scanned along the recording. ; Finally, a photo multiplier 
collects the photons that have penetrated the film and converts them to an 
electron flow. . 


In the 1980's, electron beam memories are considered to be cost competitive 
with all online random access stored devices (Reference 54), but with far 
superior performance. 
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3, 3. 3. 2 Array Processor Survey 

Our study included a survey of the technology of high- data -rate image pro- 
cessing in 1974-76, Figure II-3-17 summarizes some of the results of this 
survey. 

The array processor is usually comprised of an array of special purpose 
microprocessors containing processing elements (PE), viz, , algebraic, 
trigonometric, or exponential operations, which process data in parallel 
along separate paths on a bit-by-bit basis. The array processor operates in 
conjunction with a host computer which provides overall program control. 
Figure II-3-18 illustrates a typical configuration for an array processor (data 
path flow diagram for the AP-120B Array Transform Processor from Float- 
ing Point Systems, Inc). 

One of the major applications of array processors is digital image processing. 
Typical computational functions which can be solved with this processor 
include image matching, correlation, spatial transformation, image regis- 
tration, radiometric corrections, change detection, statistical classifica- 
tions, and various image enhancement techniques. Also, the array processor 

may be used to control the image display and recording equipment* 

3. 3, 3. 3 New Data Handling Concepts in the Literature 

Initially, two new data handling concepts were examined that were described 
in the published literature: (1) GE's Onboard Experiment Data Support 
Facility (OEDSF) (Reference 9) and (2) the Instrument Telemetry Packet 
(ITP) Concept, a GSFC report (Reference 10). 

The OEDSF concept is shown in Figure H-3 -19. This concept uses a matrix- 
structured pipelined processor that interfaces directly between the sensors 
and the Spacelab's CDMS, viz. , the high-rate multiplexer, high-rate data 
recorder, and the experiment computer. This processor operates similarly 
to an array processor; in addition, it handles multiple sensor complements 
and combinations of low- and high -data rates. The OEDSF would be fabri- 
cated with large-scale integration (LSI) circuits (usually defined as > 10Q gates 
per chip) and would dedicate an entire matrix to each sensor. This concept 
Would do most of the date, processing Onboard the Shuttle. : 
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EXAMPLE OF ARRAY PROCESSOR BLOCK DIAGRAM 


Figure 1 1-3-1 7. Array Processor Survey (1974-76) 



Figure 1 1-3-1 8. The AP-120B Array Transform Processor 
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Figure 1 1-3*1 9. GEs Onboard Experiment Data Support Facility Concept (OEDSF) 


There are some possible disadvantages to this concept and they are: 

A. The data throughput of the OEDSF system may be limited to 
capabilities of the onboard recording devices. 

B. There would be a limited capability to select significant 
(important) portions of the stream of image data for transmission 
to the ground. 

C. The matrix structure must be carefully designed to avoid conflicting 
mathematical operations being performed on data from different 
sensors. 

The ITP concept was described in a GSFC report and probably was addressed 
specifically for automated earth-orbiting spacecraft. Figure 11-3-20 shows a 
simplified block diagram of the ITP concept} note that most of the data pro- 
cessing takes place on the ground. The ITP concept is envisioned to handle 
data from a single sensor. Initially, the ITP would assemble the sensor data 
along with any required ancillary data and then buffer this combined format 
for subsequent downlinking or for further processing. Eater versions would 
likely include more sophisticated forms of efficient coding techniques. 
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GROUND PROCESSING 

NOTE 1: MICROCOMPUTER USED AS ITP PROCESSOR 

NOTE 2: MOST OF THE DATA PROCESSING TAKES PLACE ON THE GROUND 

Figure 11-3-20. Proposed Data Acquisition and Processing Subsystem Concept 

{A. Ferris and E. Green, A Proposed Conceptfor Improved NASA Mission Data Management Options, GSFC, 
X-533-76-81, October 1976) 

The onboard equipment will be comprised of multiple ITP processors and a 
single multiplexer which is used to route the ITP data to designated output 
devices (e. g. , transmitter or recorders). The ITP processor may: be imple- 
mented as a microcomputer comprised of a microprocessor; a semiconductor 
memory, read-only memory for program execution and random access 
memory (RAM) for buffer storage; and a I/O control unit. 

3. 3, 3. 4 New Advanced Concept 

A third concept was devised during the last phase of the study and is shown in 
Figure II-3-21, This concept is proposed to accomplish the onboard data 
handling task for a high-data rate image sensor. A new equipment complement 
is required that includes (1) a special-purpose microprocessor used as a 
pattern recognizer, (2) a high-speed first-in/first-out buffer, (3) a pipelined 
array processor, (2) a high-speed and capacity recorder, and (5) an inter- 
active quick-look display. 

Onboard Processing 

Most of the image sensors are observing phenomena (e. g. , solar flares) that 
occur only occasionally for short periods of time, but at extremely high data 

rates. A pattern recognizer, coupled to a first-in/first-out buffer memory; 
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GROUND 

TRANSMISSION 


KEY ITEMS 

1) DATA COMPRESSION: TYPICAL ACHIEVABLE COMPRESSION RATIOS ARE4T0 10:1 


2) THE RECORDER MUST BE ABLE TO RECORD SHORT-DURATION HIGH-DATA-RATE SIGNALS AND PLAYBACK 
AT SLOWER SPEEDS (o.g., BIPOLAR, BUBBLE, AND CCD MEMORY SYSTEMS) 

3) PATTERN RECOGNIZER/IMAGE SEGMENTER CAN ISOLATE SIGNIFICANT EVENTS AND DISCARD THE REST 

4) A CAPABILITY SHOULD EXIST FOR ONBOARD INTERACTIVE GRAPHICS WHICH CAN ALSO BE TRANSMITTED 
TC THE GROUND (NOTE: THE DISPLAY WILL ILLUSTRATE PROCESSED/CODED DATA) 

5) FOR HIGH RELIABILITY OF THE EXPERIMENTS, SPECIAL SOFTWARE DIAGNOSTIC SCHEMES WILL BE NEEDED 

•THE DATA FOR THE QUICK-LOOK DISPLAY IS TIME SHARED WITH THETR ANSMitTED DATA 
(i.e„ DATA STEALING); HENCE, THE HIGH-SPEED RECORDER SERVES A DUAL ROLE 

Figure 11-3*21. New Onboard Data Handling Concepts 


an array processor used to compress the data; and a high-speed digital 
recorder will permit detecting the appropriate signals and recording for 
subsequent transmission at a low -data rate. The pattern recognizer will be 
implemented by a microprocessor which can also be used for trend analyses, 
image segmentations, and the initiation of control signals to the rest of the 
image sensor processing equipment. This microprocessor will isolate the 
significant events and discard unnecessary data. The high-speed buffer 
simply controls the input rate to the array processor. 

The array processor will be used for image data compression. Image com- 
pression techniques (References 57 to 67) can achieve a reduction in data 
rate and volume of 4:1 to 10:1. Examples of such techniques are; (1) low- 
spatial -frequency notch filtering followed by contrast stretching and 
(2) Hadamard transformations (Reference 65) combined with removal of 
high, low- valued, sequency components (also called zonal filtering). The 
lata is then routed to a high-speed capacity record.er. 
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The recorder must be able to record short-duration high -data-rate signals 
and playback at slower speeds. Bipolar, CCDs, or magnetic bubble systems 
may be used for this device. The recorder's output will be routed to the 
Orbiter transmitter and to an interactive onboard display. The data for the 
quick-look display will be time shared with the transmitted data which means 
that the same data will be sent to both locations. It should be noted that the 
display will have to accommodate compressed and encoded data. 

Special uplink commands will be required for interaction with the quick -look 
display and simultaneous transmission of the display signal to the POCC 
which will provide a real-time check of the experiment and permit early 
remedial actions to take place. This establishes a requirement for onboard 
interactive graphics. 

Because of the importance of assuring the correct operation of the experi- 
ments, some form of diagnostic software should be placed onboard for detecting 
a failure and recommending corrective actions. 

Ground Data Processing 

The following data handling concepts ate recommended for the real-time 
Spacelab processing site (e. g. , JSC) which also includes the POCC. 

Hadamard {or other transforms, see Reference 42) decoders will be required 
to decode the quick-look data transmitted from the Spacelab. An array 
processor will be used to perform the inverse transformation necessary to 
display the visual image. Image processing at the JSC POCC would be limited 
to quick-look analysis and evaluating the quality of the downlinked data! 

It is also suggested that users who wish to communicate directly with the 
Spacelab be allocated a coded audio signal (e. g. , a voice-print signal match) 
that the user can enter into a teiephbne line for facilitating identification and 
organization of the eligible users. A central switchboard at the POCC will 
determine the order in which the users will have access to the Spacelab. 

The users at the JSC POCC are a subset of the complete set of Spacelab 
experiment users. These users will want a quick look at their data. 

Displaying this data to them will require fast decoding, array processing. 



and interpretation o£ the users 1 high-level -language commands. Thus, 
responding to the users requires a substantial amount of fast digital infor- 
mation processing. The amount of this processing available to the users is 
limited, thus, the users must compete for the available digital processing. 

The scheduler /controller will arbitrate among these users' conflicting 
demands. Depending on each user's commands, the format of the user's 
data, the information density of the user's data, the relative importance of 
the data, and the amount of preceding computing time consumed by the user, 
the scheduler must arrange (1) the sequence and sizes of the data blocks to 
be stored in the high-speed mass storage (see Figure H-3-23), and (2) the 
sequence and frequency of the running of each user's display program. The 
schedule will be implemented as software in the scheduler/contr oiler. 

Storing the data blocks in the high-speed mass memory requires a reservation 
of segments of the mass memory for the elements of these blocks as they 
arrive from the decommutator. The addresses of the heads of these blocks 
are conveniently stored in an associative memory (see Reference 68) within 
the scheduler /controller. The associative nature of this memory facilitates 
responding to each user's request for various types of data. 

Where a user's program, say user A's program, is suddenly interrupted by 
another user, B, and user B has a higher priority than user A, then user A's 
intermediate data may be stored at the top of a stack memory (Reference 68) 
(or, equivalently, a push-down memory). The intermediate data of user A 
will be retrieved when user B's program is completed. If a still higher- 
priority user, C, interrupts user B, then user. B's intermediate data are 
stored at the top of the stack (pushing down the data of the other users in the 
stack) until user C's program is completed. This computer algorithm 
structure will not only determine priorities but facilitate day-to-day changes 
in the scheduling of the experiments. 

Because of the importance of correcting experiment failures as rapidly as 
possible and since a full diagnostic and repair capability will not be feasible 
onboard the Shuttle, it will pr obably be necessary to have a full failure 
analyzer on the ground (JSC and MSFC). The analyzer will assist JSC POCC 
to advise the Spacelab on remedial actions for hardware and SbftWaxe failures 
that the onboard system cannot cope with. 
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Suppose a hardware failure occurs in the data processing section of the Space- 
lab and either (1) this hardware failure cannot be diagnosed onboard or (2) the 
hardware failure can be diagnosed but a repair procedure cannot be discovered 
onboard — perhaps because of a lack of an appropriate spare part. Then a full 
simulator of the onboard data processor, including a capability for simulating 
hardware failures, may enable the POCC crew to suggest alternate schemes 
for at least a partial repair. 

Suppose a software failure occurs that is too complex to be diagnosed onboard. 
Then, a full simulation of the system is needed at JSC or MSFC, To enable 
this simulation to take place, a full memory dump from the onboard computer 
system to the JSC simulator would provide the JSC programmers the infor- 
mation they need for a diagnosis of the failure, and for finding schemes for at 
least a partial repair. 

The analysis of hardware and software failures is likely to be greatly helped 
by special software written as a diagnostic aid. We refer to this as diagnostic 
software. 

The following data processing techniques are suggested for non-time -critical 
processing of Spacelab data at GSFC. Also, array processors will be 
required to implement the appropriate (e, g. , Hadamard) decoding technique 
needed to restore the images into a visual scene. 

At this site, the data is received in the form of a variety of waveforms multi- 
plexed together, nonmultiplexed signals, medium-rate data, and high -data - 
rate image sensor data. Most of the new data handling concepts presented 
here are only concerned with image processing since the analysis of non- 
image sensor data is well within the current state of the art. 

Figure II-3 -22 is a table that lists standard digital image processing 
techniques which should be considered for GSFC and examples of their 
corresponding applications. These techniques are discussed in detail in 
Reference 42 and will hot be elaborated on in this report. It should be noted 
that some real-time processing algorithms may be included at this site. For 
example, as sociative memory designs may be used to facilitate dynamic 
loading of new programs. Also, data base processing (Reference 41) may be 
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FUNCTION 


EXAMPLES OF APPLICATIONS 


1.) DECODING 


INVERSE HADAMARD (OR FOURIER) TRANSFORMATION INTO 
VISUAL SCENES. 


2.) IMAGE SEGMENTATION 


SCENE ANALYSIS; E. G., DISCRIMINATION BETWEEN TERRAIN 
FEATURES LIKE FORESTS, URBAN AREAS, BODIES OF WATER, 
ROADS, ETC. 


3.) NOTCH FILTERING 


REMOVE SHADING EFFECTS CAUSED BY NONUNIFORM ILLUMINATION. 


4.) GEOMETRIC CORRECTION 


CORRECTIONS OF DISTORTIONS IN SCANNER OR TELESCOPE (OPTICS) 


5. ) INTERFRAME 

RECONSTRUCTION 

6. ) DEBLURRING 

7. ) IMAGE CORRELATION 


ELIMINATE FLICKER IN SLOW MOTION VIEWING OF RAPID EVENTS 
(E.G., SOLAR FLARES). 

CORRECTION OF DISTORTIONS DUE TO IMAGE MOTION AND 
ATMOSPHERIC TURBULENCE. 

CONSTRUCTION OFTOPOGRAPHIC MAPS FROM STEREO-PAIRS. 


8.) DATA BASE PROCESSING 


ANALYSIS AND CORRELATION OF SENSOR DATA FROM SEVERAL 
(SENSOR) FILES. 


NOTE: MOST OF THESE NEW DATA HANDLING TECHNIQUES APPLY TO IMAGE PROCESSING ONLY. 


Figure 11-3-22. New Data Handling Concepts, Non-Time-Critical (GFSC} 


used for correlating data from several sensors and can have applications for 
both quick-look analyses and visual image processing evaluations (GSFC). 


3. 3. 3. 5 End-to-End Concept 

This final section will address a complete Spacelab experiment data link which 
is comprised of (1) onboard systems and (2) ground systems — real-time 
processing (JSC) and ground systems and non -time -critical processing (GSFC) 
This end-to-end concept is illustrated in Figure II-3-23. 

Onboard Processing 

Since the low -rate data will be received at the onboard data handling interface 
with widely varying speeds and waveform spectra, this data will be processed 
by LSI -designed microcomputers. The processing will be comprised of 
buffering, formating plus data correlation, and simple forms of data com- 
pression, if desired. The low -rate data streams will be multiplexed into a 
single bit t tream which is in turn combined with the high-data rate Signals 
in the HRM. 

Because of the immense data rates produced by some of the image sensors, 
it is necessary to use parallel processing techniques where possible. This 
can be implemented by array processors in which the mathematical operations 
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Figure 11-3-23. Model of an Advanced End-to-End Data Handling Concept 


are distributed throughout an array structure and the data is pipelined (at 1 to 
4M words per second data rate) through the processor. Use of high -capacity, 
fast-access memory devices (e. g, , magnetic hubbies) will be used as buffers 
between the high-rate data processing and the HUM, A scheduler will be 
included in the HRM to provide remote control of the downlink data. 


Ground Data Processing 

Since the same or related objects are often observed by two or more imaging 
sensors, it ie desirable to correlate the data from these sensors. . For this 
purpose, a data base processor will provide a method for correlating data 
with various formats and codes. Use of programmable read-only memories 
(PROM) or other forms of firmware will expedite the implementation of the 
data base processors. Ground use of the array processors will provide the 
inverse transformation of the image data, corresponding to the selected 
onboard data compression technique. Array processors may be used for both 
quick-look analysis and data quality evaluations. 
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Computer -assisted experiment scheduling will make use of stacked and 
associative memory (software) designs. Much of the scheduling of experi- 
ments for data acquisition may be carried out by stack or push -down mem- 
ories (i. e. , last-in/fir st~out), These memories store the addresses of 
programs for initiating the acquisition of data. Associative memories are 
used to facilitate the dynamic loading of new programs. When a change in a 
program takes place, the new program must be loaded into the main memory 
from a mass storage unit (e. g. , disk). The addresses of the statements in 
this new program may be allocated with the help of an associative memory 
which designates the available space. 

Database Processing 

When data arrives from the decommutator, it is in a variety of formats, 
depending on the number of bits per sample, the time between samples, the 
number of samples to be viewed in each frame of a display, the number of 
samples per word of memory, and the information requested by the user. 

For example, the user may wish to see the correlation between two sequences 
of observations immediately following a solar flare: (1) the magnetic field 
along an earth meridian coplanar with the sun, and (2) the amount of cosmic 
ray particles in selected energy intervals. These data need to be placed into 
a data structure to facilitate the retrieval of the desired information and to 
facilitate correlating simultaneous data. 

The database processor facilitates this task by placing all the data into a 
consistent data structure, in blocks covering a specified time interval. 

These data are then retrievable for output processing and/or correlation, 
even though the user requesting the data may not be familiar with the data's 
format and data structure. 
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Section 4 

CONCLUSIONS AND RECOMMENDATIONS 

Major observations related f o the Spacelab payload data processing system 
requirements are shown on Figure II-4-1. The most overriding observation 
is that the high data rate and volume from a few Spacelab payloads are the 
most significant parameters driving ground data system design. A high per- 
centage (greater than 90%) of Spacelab digital downlink data is image data. 

It is expected that image data rates will increase in the future to levels well 
above the 50 MBPS rate as science and technology activities in orbit are in- 
creased. Simultaneous video as well as high- rate science data will be re- 
quired which will further increase transmission and handling requirements. 
In addition to these incompatibilities, other program issues are still unre- 
solved, such as the fact that most users prefer real-time mission support 
from their home sites rather than at a centralized facility. Although many 
questions remain unanswered, considerable effort is being expended at this 
time by NASA and the payload community to solve these incompatibilities. 


Conclusions from the ground data management analysis are shown on Figure 
II-4-2. Payload data processing requirements are expected to increase, but 
firm requirements are not yet available. Most users are very flexible - they 
claim, "This is what we would like, but tell us what we need to live within. 11 
Thus, data requirements are largely conceptual, and firm requirements will 
have to be evolved with payload hardware and software development. This is 
the paradox of the problem because integrated payload data requirements, 
which are not yet developed, are needed now in order to properly plan for the 
necessary ground data management system. 

It has been stipulated by NASA that the Orbiter /TDRSS link will accommodate 
data rates up to 50 MBPS, and the subsystems to accomplish this rate are 
well defined. However, the ground processing systems are limited to early 
mission, support requirements (~2 MBPS) and, therefore, these systems are 
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• HIGH DATA RATE AND VOLUME REQUIREMENTS DRIVE GROUND DATA SYSTEM 
DESIGN 

• HIGH PERCENTAGE OF DOWNLINK DATA IS IMAGE DATA (GREATER THAN 90 PERCENT) 

• IMAGE DATA RATE REQUIREMENTS WILL INCREASE IN FUTURE ( > 50 MBPS ) 

• SIMULTANEOUS VIDEO AS WELL AS HIGH RATE SCIENCE DATA WILL BE REQUIRED 
FOR INTERACTIVE CONTROL 

• MOST PAYLOAD USERS PREFER TO PROVIDE REAL-TIME SUPPORT FROM HOME SITES 

• PAYLOAD COMMUNITY AND NASA AWARE OF AND ACTING TO SOLVE PROBLEM 


Figure 11-4-1. Key Observations 
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• USER DATA PROCESSING REQUIREMENTS ARE LOOSELY DEFINED 

• PAYLOAD SENSOR OUTPUT AND DATA TRANSMISSION CHARACTERISTICS 
EXCEED CURRENT PROCESSING CAPABILITIES 

• REAL TIME IMAGE PROCESSING IS A VALID REQUIREMENT 

• USE OF CURRENT TECHNOLOGY ADVANCEMENTS ARE NECESSARY 

• EFFECTIVE DATA PROCESSING REQUIRES END-TO-END SYSTEM PLANNING 

• ONBOARD PROCESSING WILL BECOME A NECESSITY 

• A STRONG USER/ PROCESSOR UNION IS REQUIRED 


Figure 1 1-4-2. Ground Data Management Cmcluiions 



not as advanced as the TDRSS. The projected data rates greater than 50 MBPS 
will require improved onboard as well as ground processing systems. The 
ability to process image data in real time will be required to support inter- 
active payload mission operations. In order to meet the higher data rate 
payload requirements, several proposals have been made ranging from more 
sophisticated data processing designs and computing complexes to the use of 
advanced technology data recording techniques. Data compression and filter- 
ing (selective processing) at the source will become necessary using micro- 
processors that reflect the rapid developments in integrated circuits and 
other specilized equipment. A strong union of the payload community and 
the data processing community is required to allow end-to-end system plan- 
ning for an effective data processing system. 

Overall recommendations for the ground data management analysis effort are 
summarized on Figure II-4-3. It is recommended that direct action be taken 
to develop a system for the simultaneous downlinking of video and digital 
data at a rate much greater than the current constraint of 2 MBPS. Methods 
to further reduce the processing of Useless data should be encouraged such 
as the combination of onboard/ground interactive graphics combined with 
computer -assisted scheduling. In general, NASA should promote the future 
use of payload microcomputers (plus memories) rather than the use of an 
onboard centralized computer. Complete payload autonomy should be the 
goal of future planning. 

A follow-on study is recommended that would develop integrated payload data 
processing requirements and user guidelines related to payload data manage- 
ment capabilities for use by both the payload and data processing communities. 
An investigation of new electronic technology advancements needs to be con- 
ducted for application within the payload data processing system. Improved 
computer designs, such as array processors, could be used to implement 
data compression techniques. In addition, high capacity/ speed memory 
systems could be used as buffers (such as magnetic bubbles, bipolar semi- 
conductors, or charged coupled devices) and as image storage devices (such 
as laser and electron beam systems). 
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DIRECT ACTION: 

• DEVELOP SYSTEM FOR SIMULTANEOUS DOWNLINKING OF VIDEO AND HIGH 
RATE DIGITAL DATA 

• ENCOURAGE TECHNIQUES TO REDUCE THE PROCESSING OF USELESS DATA 

• PROMOTE PAYLOAD DATA AUTONOMY WITH ONBOARD MICRO-COMPUTERS 
FOR SCIENCE DATA PROCESSING 

FOLLOW ON STUDIES: 

• DEVELOP INTEGRATED PAYLOAD DATA PROCESSING REQUIREMENTS AND 
USER GUIDELINES 

• I NVEST1 GATE USE OF NEW TECHNOLOGY 

- IMPROVED COMPUTER DESIGNS FOR DATA COMPRESSION 

- USE OF HIGH CAPACITY/SPEED MEMORY SYSTEMS AS BUFFERS 
AND IMAGE STORAGE DEVICES 


Figure 11-4-3. Ground Data Management Recommendations 
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Appendix B 

SPACELAB PAYLOADS GROUND DATA HANDLING 
REQUIREMENTS QUESTIONNAIRE 

This appendix outlines a questionnaire used during this study as a checklist 
to gather ground data handling requirements via a documentation search and 
personal interviews. 

L PRELAUNCH 

Are there any prelaunch activities (i, e„ , Level I, II, or III which, require 
ground data handling operations? If so, is data handling support required in 
real time or near real time? Do any of the prelaunch tests require command 
and control from remote locations (e. g, , POCC) ? 

II. LAUNCH, ASCENT, DESCENT, AND LANDING 

Are there any data handling requirements needed during these mission phases 
Ar e there any command and control operations required during these phases ? 

III. MISSION OPERATIONS 

A. What method of downlinking the experiment housekeeping data is 
desired? What format, word size, and data rate is required? 

B. Is real- or near- real-time scientific data required by the Spacelab 

experimenter? What method of downlinking is desirable? What 
will be the data format, word size, data rates, and repetition 
rates? _ ■. ■/ . . 

C. Are ground commands and/or two-way voice required for payload 
operation? What will be the format, word size, and uplink data 
rates? What is the desired command validation method? 

D. Is (offline) temporary storage of scientific, housekeeping, com- 
mand, and voice required? What is the estimated data volume, 
duration of storage, and repetition rates required for this storage? 
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E. Is real- or near-real-time experiment data desired at a remote 
site (other than the POCC) ? Where? What type of data (e. g. , 
voice transcripts/tapes, scientific* and correlated engineering 
data) and how prompt is it required ? 

F. Are there any special computational techniques desired for use on 
the scientific data* near real-time? How often is the technique 
required? What is the quantity of data required? Computational 
speeds and output products ? 

G. What are the desired outputs from the POCG (e, g. * computer- 
compatible tapes)? 

H. What type of engineering or housekeeping data is desired to corre- 
late with the experiment data (e. g. * Orbiter trajectory* Spacelab 
attitude* instrument pointing angles, and mission timing) ? Are 
thei-e any special requirements for this data, viz* data accuracy 
and method of integrating the data with the scientific data ? 

I. Is archiving of the scientific data required? Define requirements, 
e. g. * data form (computer compatible tapes, film, etc. ), data 
volume* and duration of storage ? 

IV. POSTMISSION OPERATIONS 

A. After the mission* are there any special processing techniques 
and data output formats required by the Spacelab experimenter(s), 
either for downlinked data or data returned via the Orbiter? 

B. Are there any constraints on the postmission data volume and the 
time lines of the data delivered to the experimenters ? 

C. What type of housekeeping (or engineering) data is desired to 
correlate With the scientific data and are there any unique 
requirements for this data (e. g. , data accuracy) ? 

D. Would a centralized data processing and analysis facility be useful 
to you, if provided? 

E. What type of onboard data processing and operations would be 
useful to make the ground data handling process more cost 
effective ? 



Spacelab 

Science 

Discipline 


Payload or 
Experiment 


h Solar SQ-Ql-S 
Physics Dedicated 
Solar Sortie 
Mission 


IBM “Space- 
bb User 
Interaction 
Study, Phase 
2 Review,’* 
1975. 


2. Solar Dedicated 
Physics Solar Physics 
Payload (e.g. 
Conventional 
and Imaging 
UV Spectro- 
meter 


Balt Bros. 
“Shuttle Era 
Grnd Data 
Processing 
Parametric 
Reqmts for 
tire Disci- 
pline of 
Solar 
Physics” 
1975. 
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QUESTIONNAIRE RESULTS FOR THE GROUND DATA HANDLING OF SPACELAB EXPERIMENTS 

GROUND DATA HANDLING REQUIREMENTS - ON-ORBIT 


Information 
Source or 
Contact 


Method and Form 
of Downlinking 
the Scientific Data 


Method and Form 
of Downlinking 
Housekeeping Data 


13.2 MBPS digital 
output (photo- 
heliograph). 

TV dispby for 

crew/gionnd 

display. 

786 frames/orbit . 
Digital data sent to 
ground via trans- 
mission link or to 
high-speed recorders. 


Prelected engr par- 
ameters for failure 
.detection-onboard 
or ground monitor. 


Data rates range 
from 1.82 kBFS 
to 7.28 MBPS. 
Shuttle stipulated 
TLM format: 

8 bits/word or inte- 
ger multiple. 

Frame is an integer 
multiple of 16 bits. 
Max frame length; 
8,192 bits. 

Nonbyte oriented 
data shall be organ- 
ized Into total 
lengths which are 
multiples of 8 bits 
The range of the 
average data rates 
for the cases studied 
are presented in 
Table 3-4. ' 


mijBomm&m I 


FAGE IS 
OF POOR QUALM 


Method of Performing 
the Command & Con- 
trol of Experiments 


Temporary Storage 
Reqmts for the 
Downlinked Data 


Remote Site Data 
Requirements 
(other than POCC) 


Video dispby used for 
proper target selection 
and accurate instrument 
painting. 

Sample full target 
images, saving oniy 
image changes of a pre- 
scribed magnitude. 

Devise convenient (on- 
board) sensor calibration 
techniques to improve 
the overall scientific 
data quality, 


Telemetry overhead 
and housekeeping 
data assumed to be 
10 % of the scientific 
data rate. 

The telemetry data 
Is Integrated with 
the scientific data. 


A video uplink is pro- 
posed for processed 
Images to be used by the 
payload specialist to aid 
in experiment operations. 
Data storage and turn- 
around time require- 
ments may preclude 
the use of the 50 MBPS 
data link for control 
purposes and the 
2 MBPS downlink 
may have to be used 
instead. 


Wrap-around record- 


Sden 

ing technique storing 


from] 

only current data 


elimij 

history to reduce 


onbo 

overall data volume- 


pioc< 

onboard or ground 


Comj 

scheme. 


and t 
duph 



smg.j 

Soffij 

ment 



e.g., i 

data 

data^ 

Prep 

duct 

data 

i 

Storing data from 2 

Data from the 

Mngn 

to 7 days; for ex- 

TDRS ground sta- 

A da" 

periments including 

tion will be relayed 

teclir 

the imaging UV spec- 

to a preprocessor 

Sec, *. 

trometer requires 

facility, then sent 

Refo 1 


data storage capability 
ofMxlO 1 * bits (see 
Table 4-2). 


to a control facility sclen 
and placed on com- wind 
puter-compatible raste; 
tapes which are (see ! 
sent to an analysis j 
facility* j 

The functions to 

designated for the Hsl 
preprocessing and 4 , 5 ^ 
control facilities can j 7 ng |j 
be considered to be S j a n i 
included in the POCC loo ^ 
(see Sec. 4.2 and 4.3) com ) 
The analysis facility equa 
(which may be in- 
cluded in the POCC) in „ : , 
will: (I) archive are f 
images witii little sci- v . • 
entific info and ( 2 ) . 1S1 1 

process images of sci- 
entific value (see a 

Sec 4.4.1) P1 ° 

algoi 

Stall 


i 


Table C-l (Page 1 of 6) 

FOR THE GROUND DATA HANDLING OF SPACELAB EXPERIMENTS - MISSION OPERATIONS 
GROUND DATA HANDLING REQUIREMENTS - ON-ORBIT 


Form 

rcking 
ig Data 

Metltud of Performing 
the Command & Con- 
trol of Experiments 

Temporary Storage 
Reqmts for the 
Downlinked Data 

Remote Site Data 
Requirements 
(other than POCC) 

Application of Special 
Computational 
Techniques 

POCC Desired 
Outputs 

Method and Type 
Correlated House- 
keeping Data with 
Scientific Data 

Data Storage 
Requirements 
at the POCC 

gr par- 
ilufe 
board 
niton 

Video display used for 
proper target selection 
and accurate instrument 
painting. 

Wrap-around record- 
ing technique staring 
only current data 
history to reduce 


Scientific data sampler 
from high-rate output to 
eliminate useless data- 
onboard or ground 


Sample instrument 
line nnise vehicle 
control/stability and 
hardware gimbal 



Sample full target 
images, saving only 
image changes of n pre- 
scribed magnitude. 

Devise convenient (on- 
board) sensor calibration 
techniques to improve 
the overall scientific 
data quality. 


A video uplink is pro- 
posed for processed 
images to be used by the 
payload specialist to aid 
in experiment operations. 
Data storage and turn- 
around time require- 
ments may preclude 
the use of tin- 50 MBPS 
data link for control 
purposes and the 
2 MBPS downlink 
may have to be used 
instead. 


overall data volume- 
onboard or ground 
scheme, 


Storing data from 2 
to 7 days; for ex- 
periments including 
the imaging tIV spec- 
trometer requires 
data storage capability 
ofMxlG 1 2 bits (see 
Table 4-2), 


Data from the 
TDRS ground sta- 
tion will be relayed 
to a preprocessor 
facility, then sent " 
to a control facility 
and placed on com- 
puter-compatible 
tapes which are 
sent to an analysis 
facility. 

The functions 
designated for the 
preprocessing and 
control Facilities can 
be considered to be 
included in file POCC 
(see Sec. 4.2 and 4.3) 
The analysis facility 
(which may be in- 
cluded in file FQCC) 
will: (1) archive 
images with little sci- 
entific info and (2) 
process Images of sci- 
entific value (see 
Sec 4,4.1} 


processing.. 

Comparison of current 
and past data to avoid 
duplicate data process 
sing. 

Software editing of instru- 
ment data eliminating, 
e,g„ instrument saturated 
data and out-of-tole ranee 
data, 

Preplanned data range re- 
duction due to evolved 
data system confidence. 

Magnitude decoding: 

A data compression 
technique (see 
Sec. 4,5.1). 

Reformatting: separating 
scientific data into arrays 
which correspond to a 
raster or spectral scan 
(see Sec 4.5,2). 

Image registrations: trans- 
formation of image paints 
to correct for p re-estab- 
lished criteria (see Sec. 
4,5.3). 

Engineering unit conver- 
sion; (1) conversion via 
- look-up tables and (2) 

) conversion via math 
equations. 

Measurement limit sens- 
ing: data outside limits 
are flagged. 

Visual display proces- 
^ sing; Scale scientific 
data and drive displays. 
Plotting and histogram 
algorithms,. 

Statistical computations. 


jitter. 

Sample payload 
sensor outputs to 
supplement target 
selection function. 


Tire outputs 
from the pre- 
pro cessing/con- 
trol facilities 
will be (see . 

Fig. 4.3 and 
Table 4-3) 

• Scientific data 

- High-quality 
visual display 
hard copies 

- Hard copies 
of CRT plots, 
histograms, and 
data summaries 

-High-speed 
printer tabula- 
tions 

. - image and 
tabular micro- 
film 

« Housekeeping 
data 

-Hardcopies 
of CRT plots, 
histograms, and 
data summaries 

- High-speed 
printer tabula- 
tions 

-Tabular 

microfilm 


Initially the integrated 
housekeeping/scientific 
data are time corre- 
lated and separated 
into two data records, 
Housekeeping data 
are converted to 
eng ring units prior to 
being recombined 
with file scientific 
data. 

The formatter com- 
bines the appropriate 
housekeeping data 
with the scientific data. 
There shall be real or 
near real-timelimit 
checking and trend 
analyses performed 
on tlie housekeeping 
data for display and 
hard copy recording. 


See Table 4-2. 




^ 4 ® 



The addition of on- 
board data process- 
ing is required to 
provide for down- 
linking for sensor 
data for quick-look 
analysis. 


2, Earth Synthetic 
and Aperture 
Ocean Radar (SAR) 
Physics 


IBM “SAR Use of sensor dur- 

GrDund ing the mission 

Data Pro- varies from 2.5 to 

cessing 26 hours, 

Facility Def- 
inition The sensor data rate 

Study,” Jan is approximated at 

1976. 197 MBPS. 


The data volume is 
estimated to vary 
from 2.84 x 10*2 

to 29.6 x lOl^bits 
permission. 
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Method and Type 

Remote Site Data Application of Special Correlated House- Datastorage 

Requirements Computational POCC Desired keeping Data with Requirements 

(other than POCC) Techniques Outputs Scientific Data at the POCC 


i None given. 

For rsal-time housekeep- 

One of the Multiplexed with the 

Image data 


ing data processing 

major facets of scientific data. 

stored on 


(1) decommutation and 

the system is 

HDT’smay 

>y 

data conversion (2) limit 

to provide a 

total between 

eh 

checking, trending and 

storage/retrieval 

50 and 200 


plotting, (3) tabulate 

capability of the 

tapes per mis- 

0 

vehicle position and atti- 

scientific data 

sion, (See 

/in. 

tude, £4) establish sensor 

for the experi- 

Fig, 4,5-10). 

th 

status, and (5) manage 

ment user. 

Tliis same data 

L 

ground recorders. 


would require 
between 

han 

For quick-look process- 


27,000 & 


ing - evaluation of data 


75,000 com- 


compressed radar images. 


puter-compati- 
ble tapes - 


(CCT) which 
are character- 
ized as 2,4 OU 
feet long with 
9 tracks at a 
packing dens- 
ity of 1,600 
bit/in. 





Spacelab 

Science 

Discipline 


Payload or 
Experiment 


L Earth Earth Viewing GE “EVAL 

Observa- Applications Concept 

tions Laboratory Definitions/ 

(EVAL)-Pay- Partial Space- 
load Analyzed, lab Payload 
Consists of Technical 

15 Sensors Report,” 


Technical 
Report,” 
Sept 1976. 
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QUESTIONNAIRE RESULTS FOR THE GROUND DATA HANDLING OF SPACELAB 

GROUND DATA HANDLING REQUIREMENTS - C 


Information 
Source or 
Contact 


Method and Form 
of Downlinking 
the Scientific Data 


Method and Form 
of Downlinking 
Housekeeping Data 


Assuming 11 sensors 
arc on simultaneously, 
the data rates vary 
from 320 BPS to 
120 MBPS. 


The data rate of the 
thematic mapper 
(TM) is estimated to 
be 120 MBPS, 


The sum of the data 
rates (excluding the 
TM) is approx, to 
be 636 kBPS. 


The TM sensor is 
estimated to gen- 
erate 6 x IQ 11 
bits/day. 


Although downlink- 
ing the data is fea- 
sible via the TDRSS 
at 50 MBPS, thrift* 
feel the current 
EVAL requirements 
can he satisfied 
simply with the data 
returned by the 
Shuttle. 


2. Earth EO-06-S 


Obser- Seven-Band lab User 

vations Multispectrai Interaction 

Scanner Study, 

(MSS) Phase 2 


IBM “Space- The estimated data 


Study, 
Phase 2 
Review,” 
May 1975. 


rate 240 MBPS, 
All data to be re- 
turned via the 
Shuttle and no on- 
orbit dump of the 
data is anticipated. 


Method of Performing 
the Command & Con- 
trol of Experiments 


Temporary Storage 
Reqmtsfortlie 
Downlinked Datu 


The standard equip- 
ment onboard the 
Spacelab can neither 
buffer nor directly 
handle the 120 MBPS* 
It is recommended 
that a very high-rate 
data recorder 
(VHRDR) be added 
onboard the Space- 
lab characterized 
by: 

• Data rate-120 
MBPS : 

• Packing density- 
20 kBPS 

** Record/playback 
speeds- 15 0/50, 
20in./scc 

• Data Storage - 
2x10^ bits/reel 


On-orbit control only 
with MSS displays and 
controls mounted 
within the Spacelab. 
Provide a televised 
telescopic view of the 
terrain being observed 
by the MSS. 

Use onboard processor 
providing data sampling 
technique to screen un- 
desirable data. 


Nominal flight dura- 
tlon.of 7 days 
estimated. 


30 observations 
intervals/mission 
with a 25% duty 
cycle for each 
hour of the mission. 


Data to be recorded 
onboard the Space- 
lab and will require 
approx 27 reels of 
tape for an esti- 
mated 2.7xl0 12 
bits of MSS data. 



stiiod and Form 
fDawnKjiklng 
usekeeping Data 


Method of Performing 
the Command & Con- 
trol of Experiments 


Temporary Storage 
Reqmtsforthe 
Downlinked Data 


Remote Site Data 
Requirements 
(other than FOCCJ 


Application of Special 
Computational 
Techniques 


POCC Desired 
Outputs 


Method and Type 
Correlated House- Data Storage 
keeping Data with Requirements 
Scientific Data at the POCC 


The standard equip- 
ment onboard the 
Spacelab can neither 
buffer nor directly 
handle the 120 MBPS* 
It is recommended 
that a very high-rate 
data recorder 
(VI-IRDR) be added 
onboard the Spacc- 
lab characterized 
by: 

* Data rate- 120 
MBPS 

• Packing density- 
20 kB PS 

* Record/playback 
speeds- 150/5 Q> 

20 in./sec 

• Data Storage- 
2x10* 1 bits/reel 


The current EVAL 
system was esti- 
mated to have 
18 tapes {© 

2 x 10 1- 1 * bits/reel) 
from the VHRDR 
and one tape 
from the stand- 
ard Spacelab 
HDRR(g3.44x 
109 bits/ieel) 
plus film from 
the large 
format camera 
for each 6-day 
mission* 


On-orbit control only 
with MSS displays and. 
controls mounted 
within the Spacelab. 
Provide a televised 
telescopic view of the 
terrain being observed 
by die MSS* 

Use onboard processor 
providing data sampling 
technique to screen un- 
desirable data. 


Nominal flight dura- 
tion of 7 days 
estimated. 

30 observations 
intervals/mission 
with a 25% duty 
cycle for each 
hour of the mission. 
Data to be recorded 
onboard die Space- 
lab ind will require 
approx 27 reels of 
tape for an esti- 
mated 2.7xl0 12 
bits of MSS data. 
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QUESTIONNAIRE RESULTS FOR THE GROUND DATA HANDLING OF SPACELAB EXPERIMENTS - MIS 
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Spacelab Information Method and Form Method and Form Method of Performing Temporary Storage Remote Site Data Application 

Science Payload or Source or of Downlinking of Downlinking the Command & Con- Reqmtsforthe Requirements Compute 

Discipline Experiment Contact the Scientific Data Housekeeping Data trol of Experiments Downlinked Data (other than PQCC) Techni 


Ad- 

EO-3, 

Aeronutronic 

The data format Is 

Telemetry data will 

LRC personnel at JSC to 

^Minimum input 

DRS reqdto accept 

The comput; 

vanced 

EO-7/8, 

Ford "Lang- 

byte (8 bits) or 

include Spacelab sys- 

do the ATL command- 

buffer reqmts for the 

and reformat the 

quire ments ( 

Tech- 

NV-1, 

ley Applica- 

multibyte oriented; 

tems data, experiment 

ing; limited command 

data reformatting 

recorded data for 

at the DRS) 

nology 

NV-3, and 

tion Experi- 

for format struc- 

equipment data* and 

capability should exist 

system (DRS) are 

each experiment 

Tables 5.2-6 

Labora- EO-9 are Five 

ments Data 

ture (see sec. 

Shuttle systems data. 

at LRC for specialized 

given per experiment 

(located at LRC, 

for each exp 

tory 

of the High 

Management 

4.3.L2). 


experiment manage- 

in Table 5,1-1. 

JSC, or GSFC). 


(ATL) 

Data Rale Ex* 

System 


Overhead/housekeep- 

ment and contingency 




Mis- 

periments 

Study Final 

For data rate and 

ing allocated data 

situatlons-the com- 

The data volume for 

A payload control 


sion 

(see Table 

Report,” 

data voi, see 

rates are given in 

mands Will be routed 

5 experiment group- 

center (PCC)reqd 



4.3-1, ref.) 

Dec 1975. 

Table 4.3-35 

Sec 4,3,2 to 4,3,7 

via JSC. 

ings are given in 

to remotely moni- 






per each experiment. 


Tables 5.2-1 thru 

tor and control the 





Data rate reqmt 


Air-to-ground voice 

5.2-5 on a per mission 

checkout sequence 





in bits per sec 

Estimated data rates 

capability for scientific 

basis -the data vol- 

of the ATL at KSC 





max: 

for info reqd at the 

operations at the POSC!. 

ume ranges from 

(located at LRC or 





EO-3 23 MBPS 

POSC; 


4.24 X 10 9 to 2.12 

KSC). 

i 

3 




EO-7/8 426 MBPS 

* Air/giound voice 

The following data cate- 

X 10" 2 bits per 

I 




each 

at 32 kBPS 

gories arc required at 

mission. 

A payload opera- 

j 




Min: <1 BPS 

* Analog or digital 

the POSC; 


tions support center 

i 

3 





duplex voice (4 

• Telemetry data (i.e., 

Approximately 88 

(POSC) reqd to 

] 




Data volume is 

channels) POSC 

Spacelab/Shuttle 

reels (7 t 200 ft/ieel) 

support missions 





estimated to be 

JSC 

systems data and 

for a medium ca- 

operations (located 





8.8 X 10* * bits 

• Telemetry: 

experiment equip- 

pacity recorder (at 

at LRC or JSC). 





per day. 

Spacelab— 5 kBPS 

ment data) 

10 kbits/m.) are re- 







Shuttle -5 kBPS 

• Trajectory data 

quired for the major 


| 





Expmt-20kBFS 

• Command 

portion of the ex- 


■ l 





• Trajectory data 

• Video 

periments (on a 


i 





at 5 kBPS 

■ Misc {i.e., comm? ’‘d 

mission basis) 


j 


• Command data histories, data logs, 

at 8 kBPS status/ verification 

• Video analog at messages, enviion- 

4,2 MHz bandwidth mental data, sjmula- 

• Miscellaneous at tion, training data, 

5 kBPS and consumable usage 

• Voice duplex links 
POSC/ JSC 


^Buffer requirements in bytes (8 bits/word) Total * 851 ,044 

Max: EO-3-8 14,464; EQ-7/8- 17,598 
Mean (excluding EO-3/7/8) = 904 
Std.dev - 942 

**2,400' tapes, 1,600 characters per inch 
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rage 

Remote Site Data 

Application of Special 


Method and Type 
Correlated House 

Data Storage 

lie 

Requirements 

Computational 

POCC Desired 

keeping Data with 

Requirements 

>ata 

(other than PQCC) 

Techniques 

Outputs 

Scientific Data 

at the POCC 


It 

DRS reqd to accept 

The computational re- 

Decani of pay- 

or the 

and reformat the 

quirements (to he done 

load data 

ng 

recorded data for 

at the DRS) are given in 

streams (up to 

re 

each experiment 

Tables 5.2-6 and 5.2-7 

2 MBPS), 

iment 

(located at LRC, 

for each experiment. 



JSC.orGSFQ. 


Deliver payload 
data greater 

efor 

A payload control 


than 2 MBPS in 

oUp- 

center (PCC)reqd 


raw data format. 

L 

to remotely monk 



:U 

tor and control the 


Generation of 

mission 

checkout sequence 


computer-com- 

Voh 

of tile ATL at KSC 


patible tapes 

n 

(located at LRC or 


(CCT) for offsite 

1.12 

KSC). 


scientific data 


A payload opera- 
tions support center 


processing. 
Provide hard 

88 

(POSCJreqdto 


copy of payload 


support missions 


data less than 

i- 

operations (located 


2 MBPS. 

(at 

at LRC or JSC); 


Communication 

e re- 





links between 

X- 



the POSC and 
JSCarereqd 


for voice TM, 
TV, and trajeo 
tory data. 


The no, of 
CCTs*'* for 
each exper- 
ment is given in 
Table 5.2-8 - 
total of 16,584 
CCTs (at 1,600 
characters per 
in.). 
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Spacelab Information Method and Form Method and Form Method of Performing Temporary Storage Remote S 

Science Payload or Source or of Downlinking of Downlinking the Command & Con- Reqmts for the Require 

Discipline Experiment Contact the Scientific Data Housekeeping Data trol of Experiments Downlinked Data (other thai 


1, Astron- 
omy 


3m Large-Space IBM “Ground 

The ground data 

The data rate attribu- 

The major data system 

The expert 

Telescope 

Support Re- 

handling system 

ted to the pointing 

driver will be the com- 

data procei 


quirements 

requirements for 

operation of tire 

mand and control of 

will be don 

1.5m Cryo- 

for Selected 

astronomy will be 

Eclielle spectrograph 

the experiments and 

command i 

genicaUy 

Shuttle 

established by data 

was estimated to be 

the diversity of sensor 

which is eo 

Cooled 1R 

Payloads, 41 

volume as opposed 

20 kBPS (see 

applications- 

wltliremo^ 

Telescope 

Aug 1975* 

to high data rates* 

See3.2,3 J A.b) 

common ir 


(Sec 3) 



A PI requires real- 

meni effec 

30m IR 


Data dumps may 

The housekeeping 

time control of the 

the spectru 

Interferom- 


occur at fixed 

data rate for the 

. experiments*. 

data* 

eter 


intervals with 

Eclielle spectro- 




dump durations 

graph was consid- 

Real-time control 




ranging ftom a 

ered a small frac- 

requires accurate 




few see to min at 

tion of the 

pointing of the tele- 




data rates approx 

scientific data. 

scopes and monitor- 




1 MBPS. 


ing the housekeeping 
data from each 

i 



The raw downlink 


instrument* 

i 



data is placed on 

computer-com- 


The frequency of 

. ] 



patible or high- 


the painting operation 




density tapes. 


depends on the drift 

I 


of the attitude control 


system. 



j 
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Method and Type 

md Form Method: of Performing Temporary Storage Hem ote Site Data Application of Special Correlated House- Datastorage 

nlinking the Command & Con- Reqmts for the Requirements Computational PQCC Desired keeping Data with Requirements 

cpingDattt trol of Experiments Downlinked Data (other than POCC) Techniques Outputs Scientific Data atthePOCC 


rate attribu- 

The major data system 

The experiment 

The data system will be 

The output is 

Use mean and standard The estimated 

3 pointing 

driver will he the com- 

data processing 

required for instrument 

CCTs of scien- 

deviations of certain 

data volume for 

i of the 

mand and control of 

will be done at a 

limit checking, trend 

tlfic data for 

housekeeping data, 

the Echelie 

pectrograph 

the experiments and 

command facility 

analysis, plotting, and 

use in scien- 

e,g«, spectrograph and 

spectrograph 

lated to be 

the diversity of sensor 

which is concerned 

histogramming. 

tific analyses* 

vidicon temperatures, 

will range from 

(see 

applications. 

with removing 



voltages, attitude 

10 11 to6X10 ls 

&b) 


common instru- 

Evaluate the functional 


reference data, etc* 

bits per year 


A PI requires real- 

ment effects from 

performance of the call- 



(see Figure 

ekeeping 

time control of the 

the spectrum 

bration sources, 


Quick-look checks 

3.2-12), 

for the 

experiments. 

data* 



should be made of in- 


?ectio- 



Make sure the target 


formation on the sys- 

The estimated 

sconsid- 

Real-time control 


source of radiation is a 


tem pointing and in 

data volume for 

all frac- 

requires accurate 


member of the class 


spectral- and spatial- 

the mid-IR 

le 

pointing of the tele- 


being studied. 


(telescope spacing) 

Fourier spectrom- 

data. 

scopes and monitor- 




sampled data. 

eter will range 


ing the housekeeping 


The processing is divided 



from IQ 13 to 


data from each 


into two categories? ana- 


The telescope ephem- 

10 1 4 bits per 


instrument. 


lytical and experimental 


eris data should be 

year (see Fig. 




data processing. 


merged with the pro- 

3.3-5)* 


The frequency of 




cessed images which 



the pointing operation 


The analytical data pre* 


are placed on CCTs. 

The spatial inter- 


depends on the drift 


cessing will be used by 



ferometer writ 


of the attitude control 


the PI to make command 


The CCTs should con- 

approach 0,5 X 


system. 


& control decisions. 


tain a profile of the 

10 6 bits per 


calibration spectrum, mission (see 

Statistical algorithms are Sec 3.4,7)* 

required to estimate the 
spectral SNRs. 

Preprocessing of the raw 
data consists of format, 
and unit conversions 
image distortion and 
radiometric corrections, 
data filtering and data 
compression* 

Image processing will re- \ 

quire spectra convolutions, j 

fast Fourier transform and ; 

discrete Fourier transform 1 

algoritlrms and spectrum j 

SNR calculations. 


Instr modeling algorithms 
will he used to m onitor 
gradual instr degradation 
during the mission. 
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Table C-l (Page 6 of 6) 

QUESTIONNAIRE RESULTS FOR THE GROUND DATA HANDLING OF SPACELAB EXPERIMENTS - f 

GROUND DATA HANDLING REQUIREMENTS - ON-ORBIT ‘ 


Spacelab 


Information 

Method and Form Method and Form 

Method of Performing 

Temporary Storage 

Remote Site Data 

Applicat 

Science 

Payload or 

Source or 

of Downlinking of Downlinking 

the Command & Con- 

Reqmts for the 

Requirements 

Com 

Discipline 

Experiment 

Contact 

the Scientific Data Housekeeping Data 

troi of Experiments 

Downlinked Data 

(other than PQCC) 

Te< 

L Space 

SP-145 Com- 

NASA-MSFC 

There is no reqmt The housekeeping 

Voice communications 

The onboard record- 



Pro- 

prised of the 

“Spacelab 

for analog, TV, or data rate is estimated 

may be used to control 

ing rates and sto* ^ 



cessing 

following Sub- 

Design Ref. 

film data to be to be less titan 10 

the experiments. 

capabilities of -otn 


0 

Appli- 

elements: 

Mission 

downlinked, up- BPS. 


the Spacelab recorder 



cations 

(1) biological, 

Analysis - 

linked, or stored 


(rate in: 1,2,4, 8, 




(2) general 

VoIP/ Mis- 



16 & 32 MBPS and 




purpose, 

sion C - 

The max data 


storage of 3.6 x 10 10 




(3) automated 

Space Pro- 

rate anticipated 


bits) and the Orbitefs 




furnace. 

cessing 

is 14.5 kflPS. 


payload recorder 




(4) automated 

Applications’* 



(rate in: 25*5 to 1024 




levitation, 


The data vol for 


kBF5 and storage of 




(5} core, and 


a 6-day mission is 


approx 3.4 xlO^ bits 




(6) power and 


expected to be 


total) are more than 




cooling. 


3.035 x 10® bits 


adequate for storing 






(annotation and 


the data during the 






calibration data 


mission, 






has not been 
included). 


For a more efficient 
design, the high re- 






The experiment 


cording rates of the 






data will be down- 


onboard recorders 






linked both in real- 


may be adjusted to 






time and near real- 


accommodate the 






time (i.e., recorder 


lower data rates of 






data playbiefc). 


the scientific data. 






The transmission 
per day is estimated 
to be 56.Sx 10G . 
bits and the rates 
may range from 
23 KBPS to 1 MBPS 
from either recorder. 




i 
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>ACELAB EXPERIMENTS - MISSION OPERATIONS 
ENTS - ON-ORBIT 



Method and Type 


Remote Site Data Application of Special Correlated House- Datastorage 

Requirements Computational POCC Desired keeping Data with Requirements 

(other than POCC) Techniques Outputs Scientific Data at the POCC | 


i: 

i 

) 


er 



uts 


t 
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Table C-2 (Page l of 5) 

QUESTIONNAIRE RESULTS FOR THE GROUND DATA HANDLING OF SPACELAB EXPERIMENTS - POSTMISSION OPERATIONS 



Method arid Type Recommended 

Spacelab POCC Special Anticipated Data of Correlated Desirability Supplemental 

Science Payload or Information Processing and Desired Volume and Housekeeping Data of a Central Onboard Data 

Discipline Experiment Source or Contact Scientific Data Outputs Time Constraints with Scientific Data Processing Facility Processing/Opeiations 



1. Solar SOOl-S Dedicated IBM “ Spacelab User Vehicle attitude data Onboard navigation 

Physics Solar Sortie Mission Interaction Study should be delivered ns scheme for automatic 

Phase 2.” Review, soon as possible either control with ground 

1975. separately or consoli- . updates for data 

dated with the scienti- collection, 

fic data. 

Radiation monitor 
added to eliminate 
degraded data sensi- 
tive to radiation 
' effects. 


Instrument for deteo 
tion/prediction of 
solar flares to reduce 
data volume and 
Improve scientific 
return. 


Need for improved 
inflight calibration of 
instruments. 
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Table C-2 (Page 2 of 5) 

QUESTIONNAIRE RESULTS FOR THE GROUND DATA HANDLING OF SPACELAB EXPERIMENTS -POSTMISSION OPERATIONS jL 



J Method and Type Recommended 

Spacelab POCC Special Anticipated Data of Correlated Desirability Supplemental 

Science Payload or Information Processing and Desired Volume and Housekeeping Data of a Central Onboard Data 

Discipline Experiment Source or Contact Scientific Data Ouputs Time Constraints with Scientific Data Processing Facility Pro cessing/Op erat ions 



I . Earth and 
: Ocean 
Physics 



Two key instruments IBM ■ ‘Ground Sup- The system should pro- 

are; imaging radar port Requirements vide the PI with the 

(synthetic aperture) for Selected Shuttle capability to observe 
and the MSS - the Payloads/ 1 Aug 1975. small segments of the 
MSS was evalua ted : data, 

in the Earth 

Observations The scientific data 

discipline study processing was con- 

sidered beyond the 
scope of the study. 

. However, because of 
the large amount of 
image data to be 
processed it was sug- 
gested to implement 
a special program- 
mable signal proces- 
sor to perform 

(1) development of 
an index tape 

(2) develop selected 
data segments from 
the raw S Alt. data- 


in order to provide 
any real-time down- 
linking of the image 
data some form of on- 
board data compres- 
sion techniques must 
be provided. 


2. Earth and Synthetic Aperture . IBM "SAR Ground May require statc-of- The anticipated 

Ocean Radar Data Processing the-art technique For turnaround time 

Physics Facility Definition registering image with will range from 1 

Study," Jmt 1976- identifiable ground to 6 month?. 

control point. The proti^mc 

time in see may be 
computed on the 
basis of 16 hr/day 
at 22 days/month 
which yields a sys- 
tem throughput ' 
data rate rungs 
between i.5 and 
245 MBPS. 


Mote: It was considered likely that the system would use liiglwlensity tapes to store the S AR raw data and that 
the major part of the scientific data processing would take place during the posfcmissfcm phase. 
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Table C-2 (Page 3 of 5) 

QUESTIONNAIRE RESULTS FOR THE GROUND DATA HANDLING OF SPACELAB EXPERIMENTS - POSTMISSION OPERATIONS 



Method and Type f ' Recommended 

Spacelab POCC Special Anticipated Data of Correlated Desirability Supplemental 

Science Payload or Information Processing and Desired Volume and Housekeeping Data of a Central Onboard Data 

Discipline Experiment Source or Contact Scientific Data Outputs Time Constraints with Scientific Data Processing Facility Proqessing/Operations 



Earth Viewing Appli- 
cations Laboratory 
(EVAL) — payload 
analyzed consists of 
15 sensors 


GE, “EVAL Concept 
Definitions/Partial 
Spacelab Payload 
Technical Rep ort, 1 ’ 
Sept 1976* 



The current EVAL sys- 
tem recommendation 
will require the proc- 
essing of 18 VHRDR 
tapes of TM data and 
1 high-rate data 
recorder tape con- 
taining the data from 
the other sensors.* 

The data are to be 
made available to the 
experimenters within 
6 to 7 days of 
acquisition. 


They recommend 
placing a VHRDR 
onboard the Spacelab 
(for specs see P 6-5). 

For later EVAL systems, 
they recommend plac- 
ing an onboard exper- 
iment data support 
facility (OEDSF) in 
the Spacelab which 
would provide proc- 
essing for quick-look 
and data compression 
techniques 


2. Earth : EO-Q6-S . .. IBM “Spacelab User 

Observations Seven-Band Multi- Interaction Study 

spectral Scanner . Phase 2 Review,’* 

May 1975. 


*Eascd on a six-day mission 
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Table C-2 (Paget 4 of 5) 

QUESTIONNAIRE RESULTS FOR THE GROUND DATA HANDLING OF SPACELAB EXPERIMENTS - POSTMISSION OPERATIONS 



Method and. Type Recommended 


Spacelnb FOCC Special Anticipated Data of Correlated Desirability Supplemental 

Science Payload or Information Processing and Desired Volume and Housekeeping Data of a Central Onboard Data 

Discipline Experiment Source or Contact Scientific Data Outputs Time Constraints with Scientific Data Processing Facility Pro cessmg/Op orations 



1. Advanced EO-3^ Aeronutronic Ford The DRS generates Based on a single In addition to The DRS will do the 

Technology EO-7/3, ‘‘Langley Application CCTs and associated mission up proxi- reformatting, the DRS major part of the 

Laboratory NV-1, Experiments Data tabulations of reror- mately 7,000 CCTs -will perform: experiment process- 

Mission NV-3, and Management System matted experiment (at 1,600 characters • Data and system ing and can be located 

EO-9 are 5 of the Study Final Report f n data and delivers the per in.) would be health monitoring at LRC, JSC, or GSFC 

data rate experiments Dec 1975. data to the PL generated by 5 high • Sync loss and data 

data rate expert- quality checks 
men Is (see Sec • Screening capability 
4.1. 1.4.2 P 4-9) * Experiment data 

annotation 


Note: The data reformatting system (DRS) performs (1) ATL integration and checkout and (2) Pos thigh t processing. 
The payload operations support center (POSC) performs the mission operations processing. 





) 


— I 





Table C-2 (Page 5 of 5) 

QUESTIONNAIRE RESULTS FOR THE GROUND DATA HANDLING OF SPACELAB EXPERIMENTS - POST MISSION OPERATIONS 


Method and Type Recommended 

Spacelab. POCC Special Anticipated Data of Correlated Desirability Supplemental 

Science Payload or Information Processing and Desired Volume and Housekeeping Data of a Central Onboard Data 

Discipline Experiment Source or Contact Scientific Data Outputs Time Constraints with Scientific Data Processing Facility Prqccssing/Op orations 


1. Astronomy 3m Large-Space 
Telescope 

L5m Cryogenically 
Cooled 1R Telescope 

30m IR 
Interferometer 


IBM “Ground The most extensive See Mission Opera- 

Support Re qmts for mass data analysis is tio ns Table, G-l* 

Selected Shuttle required for deter- 

Payloads,” Aug 1975. mining stellar abun- 
(Sec 3) dances from the spec- 

tral line strengths. 

The following are 
examples of table 
look ups to be used 
for data evaluation 

• Ionization state 
and excitation level 
for each element 

• Make a table of 
stored image recti- 
fication functions 
to determine image 
manipulation 
required to align 
the received spec- 
tral lines with the 
calibration lines 

• Table of radiomet- 
ric correction fac- 
tors for the Fourier 
spectrometer data 


AU the analytical data 
processing to be 
accomplished at a 
central facility (as 
opposed to the pre- 
processing of the 
data). 
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Appendix D 

PAYLOAD OPERATIONS FLOW AND MALFUNCTION IMPACT ANALYSIS 

(TASK 2, 2 A) 

Early in the contract period, MDAC was directed to conduct a brief systems 
analysis of the flow of payloads from the developer through integration and 
operations. The purpose of this analysis was to determine ways to minimize 
the complexity of the payload integration process, and specifically to minimize 
the risks of integration-related payload malfunctions that could bottleneck 
the flow or result in major compromises in launch availability, etc. The 
scope of the task effort was limited by MSFC direction to a brief overview of 
two areas of interest, malfunction analysis feasibility and lessons learned. 

D. 1 MALFUNCTION ANALYSIS FEASIBILITY 

A study was conducted to determine the feasibility and practicality of using 
reliability analyses of planned payloads to predict the quantity and types of 
malfunctions which might occur during Levels III, EC and I payload integration 
in order to identify preventive upstream measures. The results of the study 
indicate that sufficient data do not normally exist for experiment hardware 
to permit the reliability analysis to .occur in time to implement preventive 
actions. In addition, the quantitative results of such analyses would be 
subject to interpretation and difficult to apply to planned operations, designs, 
and budgets. Alternate techniques were evaluated with the General Applica- 
tion of Previous Experience to payload design and operations planning appear- 
ing to be the most practical approach to both prevent and cope with malfunc- 
tions during any level of integration. Section 1 of this Appendix D documents 
the detailed results of the study. 

D. 2 LESSONS LEARNED 

A brief review was conducted of previous program operations for experience 
factors and specific lessons learned to identify those with possible applica- 
bility to Spacelab payload operations flow planning so as to minimize the 
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probability of flow- stopping problems. The review and analysis for applica- 
bility yielded many operational lessons learned which can be applied to the 
Spacelab program. They are summarized and discussed in Section 2 of this 
Appendix D along with a series of checklists developed to be responsive to 
the lessons learned at discrete milestones during payload flow. 
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Section 1 

MALFUNCTION ANALYSIS FEASIBILITY 


The Space Transportation System (STS) is expected to operate routinely, 
somewhat like a modern airline, with regular schedules to be maintained. 
Many of the payloads, however, have the potential for being nonroutine due 
to their inherent research and development nature, and could disrupt or 
bottlemeck the flow schedules if not carefully planned. This study was con- 
ceived to determine if reliability analysis techniques could be used to pre- 
dict the number and type of integration-related malfunctions which might 
occur during Levels III, II, and I payload integration in order to identify 
preventive upstream measures. Objectives and general approach are 


summarized in Figure D-l. 

MALFUNCTION PREDICTION 

OBJECTIVE- DETERMINE FEASIBILITY OF PREDICTING MALFUNCTIONS IN 

LEVEL III, 11, AND I INTEGRATION AND SUBSEQUENT IDENTIFICATION 
OF UPSTREAM PREVENTIVE ACTIONS 
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APPROACH - THREE TECHNIQUES WERE EXPLORED 

1. DESIGN AND STATISTICAL ANALYSIS OF PLANNED HARDWARE 

2. STATISTICAL ANALYSIS OF PROBLEM DATA FROM PREVIOUS 
RELATED PROGRAMS 

3. GENERAL APPLI CATION OF PREVIOUS EXPERIENCE 

REFERENCES - 1P&MP INFO NOTE 5, DATED 6-16-76 
1P&MP INFO NOTE 16, DATED 7-15-76 

Figure D-1. Objectives and Approach 

Initially, discussions were held with senior reliability analysis personnel to 
seek background information and guidance. It was found that the conduct of 
a malfunction analysis for a specific experiment or experiment group would 
require knowledge of the hardware design, the design of the Spacelab and 
Shuttle test equipment interfaces, and the operational usage in the various 
test levels. Further, it was expected that specific design reliability data 


/rs/ 
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would not normally be available at tile required time to permit rigorous 
analysis leading to malfunction predictions for . which preventive measures 
could be identified and implemented in a reasonable time frame. Were it 
not for this incompatibility in timing, such analysis would be feasible. 

After initial discussions, three techniques were identified as possible candi- 
dates for predicting integration- related malfunctions: 

A. Design and statistical analysis of planned experiment hardware. 

B. Statistical analysis of problem data from previous related programs 

C. General application of previous experience to payload design and 
operations planning. 

1.1 ANALYSIS OF PLANNED HARDWARE 

A rigorous design analysis of the planned experiment hardware, coupled with 
available analysis data from Spacelab hardware systems, could yield relia- 
bility data for use in subsequent statistical probability analysis. The result- 
ing malfunctions (and rates) could then be assessed for effect on the planned 
operations, thus completing the Failure Mode and Effects Analysis (FMEA). 
The following points, summarised in Figure D-2, should be noted for this 
technique. 


EXPERIMENT DESIGN DATA NECESSARY FOP THIS ANALYSIS NOT GENERALLY 
AVAILABLE AT THIS TIME 

NUMERICAL RESULTS OF ANALYSIS MAY NOT BE DECISIVE AND WOULD 
REQUIRE EXERCISE OF CONS I DERABLE JUDGMENT IN APPLICATION 

ANALYSIS DOES NOT INCLUDE EFFECTS OF POSSIBLE QUALITY PROBLEMS, 
OPERATOR ERROR, ETC. 


ALTHOUGH NOT NOW POSS I BLE, THIS TECHNIQUE MAY LATER PROVE TO BE 
. FEASIBLE BUT MAY NOT BE PRACTICAL DUE TO COSTS AND SUBJECTIVE NATURE 
OF ITS APPLICATION 

Figure D-2. Design and Statistical Analysis of Planned Hardware 


A. Experiment design data was not generally available during the 
study to the depth necessary to support sample analyses. The 
data needed includes schematics, component design and reliability 
data, hardware descriptions, operating requirements, time lines, 
interface data, development test data, etc. Further, it was not 
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expected that this type data would normally be available for given, 
payloads in time to permit timely implementation of analysis and 
of resultant corrective measures. 

B. Analysis does not include effects of possible quality problems, 
operator or procedure errors, and the cascading effects of other 
hardware failures. 

C. Numerical results of analysis may be difficult to interpret 
sufficiently to drive decision makers decisively. 

D. This technique is expected to be feasible only if unusual efforts 
are exerted early in a payload program, but, it may not be pract- 
ical due to costs and the subjective nature of its application. It 
was thought that consideration should be given to analysis of 
selected high-cost, complex, high-potential impact payloads as 

a means of further exploring feasibility while limiting expenditure 
of resources. 

1. 2 STATISTICAL ANALYSIS OF PREVIOUS EXPERIENCE 
If data from previous payload integration experience, applicable to Spacelab, 
were available in sufficient quantity and consistency, a statistical analysis 
could produce numerically related classifications of malfunctions which 
could lead to numerical predictions of Spacelab integration malfunctions 
where hardware and/or operational equivalency can be reasonably ascer- 
tained. The following comments (summarized In Figure D-3 apply to this 
technique. 
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• ALTHOUGH LOTS OF DATA APPEAR TO BE AVAILABLE, MOST OF THE DATA 
REVIEWED THUS FAR EXHIBIT INCONSISTENCIES AND CONFUSION FACTORS 
WHICH WOULD MAKE DIRECT APPLICATION TO SPACELAB DIFFICULT, 

E.G., SKYLAB DATA CLOUDED BY N0N1 NTEGRAT1 ON-RELATED FAILURES 

• RETRIEVAL OF DATA FROM EXPERIMENT SUPPLIERS MAY BE DIFFICULT 
AND COSTLY 

• THIS APPROACH WOULD NOT LEAD TO SPECIFIC DESIGN SOLUTIONS, 

UNLIKE TECHNIQUE 1 

• APPLICATION OF NUMERICAL RESULTS WOULD ALSO BE DIFFICULT 

Figure D-3. Statistical Analysis of Previous Experience 



A. A potentially large amount of data exists for review. The review 
(up to the point of task termination by MSFC) appeared to indicate 
some inconsistencies and confusion factors which would make for 
difficult applicability to Spacelab, For example, the most directly 
applicable data available, that from Skylab, is clouded by non- inte- 
gration- related failures of many experiments. 

B. Retrieval of raw data from experiment suppliers regarding malfunc- 
tion cause and corrective actions was not attempted and could be 
difficult, time consuming, and costly. 

C. Unlike technique number one (subsection 1. 1), this technique would 
not lead to specific design solutions for expected problems but 
would provide clues and criteria for generic approaches to minimiz- 
ing problems. 

D. As with technique number one, numerical results of this technique 
could be quite subjective in application. 

E. This technique appears to lack feasibility due to inconsistencies in 
data and lack of data directly applicable to Spacelab. 

1.3 GENERAL APPLICATION OF PREVIOUS EXPERIENCE 
A thorough review by qualified personnel of previous experience applicable 
to Spacelab could be accomplished similarly to technique number two, (sub- 
section 1.2), but with less emphasis on numbers and more emphasis on ex- 
perienced judgment. This technique could lead to predictions of generic types 
of malfunctions and problems and overall guidelines and criteria for minimiz- 
ing them. The following points (summarized on Figure D-4) should be noted. 

• THIS TECHNIQUE WOULD -BE SIMILAR TO NUMBER 2 BUT WITH LESS 21321 

EMPHASIS ON NUMBERS AND MORE EMPHASIS ON EXPERIENCED 

JUDGMENT 

• THIS APPROACH WOULD APPLY PREVIOUS OVERALL EXPERIENCE FACTORS 
(QUALITY, DESIGN, HUMAN ERROR, ETC.) TO THE SPACELAB INTEGRATION 

• NUMERICAL PREDICTIONS NOT POSSI BLE, BUT RANKED CATEGORIES AND 
TREND PREDICTIONS COULD BE MADE 

• THIS TECHNIQUE APPEARS FEASIBLE, PRACTICAL, AND LEAST EXPENSIVE 

• USE OF HIGHLY QUALIFIED AND EXPERIENCED PERSONNEL TO PERFORM 
STUDY IS OF PARAMOUNT IMPORTANCE 

Figure D4* General Application of Previous Experience 
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I A. This approach could apply the previous overall experience factors 

(quality, design, human error, test conditions, etc.) to the Spacelab 
'j' integration effort. 

B. Numerical predictions are not possible but ranked categories and 
trend predictions can be made.. 

C. This technique appears feasible, practical, and least expensive. 

D. The use of experienced and qualified personnel to perform this study 
and its subsequent implementation is of paramount importance. This, 
if coupled with the use of similar personnel in the actual integration 
activities, should minimize the problems to be encountered and 

t., 

expedite solutions as necessary. 
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Section 2 

LESSONS LEARNED 

When fully operational, the STS will be required to support a high launch rate 
(up to 60 per year) in a regularly scheduled airline-type operation. To avoid 
bottlenecks in the payload integration flow it was thought that experience gained 
on past programs should be probed for possible applicability to Spacelab flow 
planning. Toward that end, a brief study was authorized by NASA to review, 
in concert with Spacelab flow plans, lessons learned on previous programs, 
and to compile those applicable to Spacelab. This section provides the results 
of that study. 


Spacelab flow plans, as documented in many studies by NASA and contractors, 
were studied first in order to provide the background against which to evaluate 
applicability of previous program's lessons learned. The programs reviewed 
(see Figure D-5) included Skylab-OWS, Skylab-AM/MDA, Saturn /Apollo, 
Gemini, Mercury, and the AMES ASSESS Program. The types of data re- 
viewed included lessons-learned documents from both NASA and contractors, 
technical reports of program operations, hardware rejection histories, and 
personal interviews with veteran program personnel. 

• PREVIOUS PROGRAMS REVIEWED FOR APPLICABLE EXPERIENCE 20291 


• SKYLAB-OWS 

• SKYLAB-AM/MDA 
•GEMINI 

• MERCURY 

• AMES ASSESS 

• DELTA 

• SATURN/APOLLO 
•SPARTAN 

• TYPES OF DATA REVIEWED 


Figure D-5. 


•LESSONS LEARNED -MDAC 

• LESSONS LEARNED -NASA 

•TECHNICAL REPORTS OF PROGRAM OPERATIONS 

• HARDWARE REJECTION HISTORIES 

• PERSONAL INTERVIEWS OF KEY PROGRAM PERSONNEL 

Lessons Learned 
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Although a wide range of source conditions and discrete lessons learned were 
evidenced., there was a general similarity in some areas from program to 
program- For example, nearly all programs stressed the importance of 
early orientation and involvement of operational personnel in order to obtain 
their input to design and flow planning and to help them in preparations to 
perform their function. Safety planning was noted to be required in early 
phases of design and flow planning, not a tag-on aftei*thought requiring com- 
promising solutions to problems. Another example of similarity is that 
nearly all programs recognized the need for a well planned, highly discip- 
lined, and timely technique for both visibility and control of all program 
actions affecting hardware availability, configuration, problems and test 
requirements. Nearly all programs developed such techniques as their 
operations matured. Early planning and program direction provides momen- 
tum, usefulness, and efficiency to such techniques. Another example which 
appears to be of great significance to Spacelab is that nearly all previous 
programs underestimated the magnitude of effort required to plan, support, 
carry out, document, and control loose flight equipment (stowage items) both 
before and during flight. Spacelab will add the dimension of between flights 
to this troublesome area. 

A list of those lessons learned, thought to be directly applicable to Spacelab 
payload integration flow planning, is contained in Table D-l. In addition, a 
series of checklists (Tables D-2 through D-7) has been compiled to be respon 
sive to the lessons learned at discrete milestones in the payload hardware 
flow planning. 

An account of problems encountered during checkout of the Skylab Orbital 
Workshop (OWS) at Huntington Beach was reviewed. The distribution of 
problems was of interest, indicating that only 11% of the total number of 
problems were due to hardware system malfunction and that 9% were mech- 
anical fit problems. The remaining 80% were due to factors unrelated to 
hardware malfunctions. These were largely problems generated upstream 
in manufacturing, engineering, and documentation processes, and all found 
by the integration team. A breakdown of the problems can be seen in 
Table D-8. 
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Table D-l (Page 1 of 3) 
LESSONS LEARNED 


1. Early orientation and involvement of all functional personnel is 
desirable to obtain their input and help them get prepared to do their 
job. 

2. Flight crew involvement is a special application of item 1 to be 
emphasized. 

3. Early identification of organizational relationships and specific 
individuals responsible for certain functions is mandatory to effect 
a smooth, efficient flow. This includes all NASA agencies and 
contractors. 

** 

4. A single, unified technique is necessary for both visibility and control 
of all program actions affecting hardware availability, configuration, 
problems, and test requirements. Should span all agencies and 
locations, and be automated. 

5. A design journal should be kept to document the design evolution, 
reasons for changes, etc. 

6. A concept should be considered in which all hardware is identified as 
falling into a subsystem with an assigned subsystem engineer manager 
who is responsible to the chief engineer and program manager for all 
program operations affecting subsystem hardware. 

7. The hardware designer should be in-the-loop from design-to- 
manufacturing-to-test and checkout- to- operation. 

8. A clearly identified document should be The Source for all test 
requirements for given systems. 

9. Checkout requirements and provisions must be considered in the design 
phase. Built-in test points and access features should be provided for 
test and troubleshooting. 

10. Early use should be made of mockups and development fixtures to 
foresee problems, train personnel, etc. 

11. Safety planning and reviews must be built in from the start and not be 
a tag- on afterthought. 

12. Uniformity of terminology, disciplines, and test procedures is desir- 
able at all locations to more easily compare operations, use transfex*red 
personnel, etc. 

13. Flight hardware should be mated and tested as a system as early as 
possible, even though subsequent operations such as shipping may 
require disassembly. 
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Table D-l (Page 2 of 3) 

LESSONS LEARNED ! 

14. Include debugging of flight operations procedures in ground checkout 
operations. 

15. Use identical GSE at different locations to enable procedure similarity, 

comparison of data, personnel familiarity, etc. ' - ; 

16. Bench testing of complex hardware should be of high fidelity, represent- 
ing, to the extent possible, in-use conditions and interfaces. Use of 

other related flight hardware In test set-ups is desirable. - 

17. Less reliance on simulators and more emphasis on installed, all-up 
systems tests is highly desirable. 

18. Discipline is necessary to force spares to be properly configured and 

rigorously tested to the same requirements as the primary flight units. ' \ 

19. Guidelines to experiment developers are necessary for both technical 

planning and operational planning. (Reference Ames ASSESS Program : „ 

Experimenter 1 s Handbooks). 

20. A central experiment repair, maintenance, and minor modification 
facility is necessary to avoid unnecessary hardware shipping, recycling, 
etc, 

21. Loose equipment to support experiment checkout must be identified and 
tracked for each location (includes GEE, CFE, miscellaneous GSE, 

etc . ) . 

22. Loose flight equipment (stowed in various ways) represents a hugepro- 
blem needing special. treatment for logistics, documentation methods, 
stowage location, scheduling, change traffic, etc (both before and 

during flight). ... : " ' . 

23. A fit check matrix should be planned for all critical interfaces of loose 
equipment, tools, etc. 

24. Every previous program has experienced severe contamination problems. ■ r "' i 

Contamination control, and personnel education therefore must start ’ 

early (includes both internal and external systems). 

25. Special attention and education for all personnel who handle hardware 

is required to preclude damage by providing tender-loving- care - ; 

attitudes. 

26. Modular packaging, access for planned operations and repairs, and .. - : 

vulnerability to damage should all be considered in designing for mini- 
mum operations problems. j 

27. Organization and operating disciplines are required to insure rapid 

feedback of problems to the appropriate personnel and to insure a rapid -- I 

response and solution. . • ; !. 
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28. Commonality of design for connecting devices must be paired with. 

consideration for the hazards of crossed- connections and appropriate 
choices made. 


29. Formal test procedures and disciplines are inexpensive compared with 
the alternatives. 

30. Every redundant path must be isolated and verified to know that it works. 

31. Electromagnetic interference can be a big problem. Electromagnetic 
compatibility must be engineered. 




Table D~2 


PRELIMINARY LIST OF PAYLOAD FLOW CONSIDERATIONS ~ 

HARDWARE ATP 

1, Provide Hardware Developer with Following: 

• Overall management plan 

• Overview and familiarization with STS 

• Detailed organizational interfaces 

• Operational requirements 

• Systems test requirements 

• Safety Criteria 

• Design criteria checklist 

• Detailed hardware interface requirements 

• Detailed flow plan 

2. Provide all Affected Agencies and Contractors with: 

• Familiarization with planned payload and hardware 

• Specific organizational contacts 

• Schedule anticipated 


Table D-3 

PRELIMINARY LIST OF PAYLOAD FLOW C ONSIDER ATIONS - 

DESIGN DEVELOPMENT 


1. PDR - Plan for Items Listed Below 

2. CDR - Measure Performance to Items Below 

3. Criteria to be Considered: 

• Design criteria checklist 

• Safety criteria 

• Systems test requirements 
■ ■ * Operational requirements 

• Detail hardware interfaces 

• Identification of potentially hazardous operations 

• Identification of damage-vulnerable hardware 

• Malfunction and failure effects on operations 

• Identification of test equipment requirements throughout flow 

• Initiate and maintain test control plan 

• Initiate and maintain design and analysis journals (logs) 

• Initiate and maintain design requirements input to visibility 
system 
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Table D~4 

PAYLOAD FLOW CONSIDERATIONS DURING FABRICATION 

1. Initiate and Maintain Fabrication Status Input to Overall Visibility System 

2. Close Follow-Up by Designers 

• Solve problems 

• Verify design intent satisfied 

3. Initiate and Maintain Quality Control Plan 

4. Initiate and Maintain Configuration Control Plan 

• Open items reported via visibility system 


Table D-5 

PAYLOAD FLOW CONSIDERATIONS DURING DEVELOPMENT TESTING 

1. Initiate and Maintain Development Test Input to Overall Visibility System 

2. Designers Responsible for Development Tests 

3. Operators and Users Monitor Tests 

• Develop inputs for downstream operations 

• Training 

4. Develop Inputs for Quality Control Plan 

5. Monitor and Feedback Information for Configuration Control Plan 


Table D-6 

PAYLOAD FLOW CONSIDERATIONS DURING ACCEPTANCE TEST 

1. Initiate and Maintain Test Status Input to Overall Visibility System 

2. Designers Involved in Acceptance Test 

3. Operators and Users Monitor (Perform) Tests 

• Develop inputs for downstream operations 

• Training 

4. Review Development Test Problems and React, as Required 

5. Maintain Quality Control Plan 

o Problem reporting via visibility system 
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Table D-7 

PAYLOAD FLOW CONSIDERATIONS DURING LEVEL V & IV INTEGRATION 


1. Initiate and Maintain Integration Status Input to Visibility System 

2. Maintain Quality Control Plan 

• Problem reporting via visibility system 

3. Review Acceptance Test Problems and React, as Required 

4. Operators and Users Monitor Tests 

5. Maintain Configuration Control 

• Report via visibility system 

6. Hardware Test 

• Fit check all interfaces (real, if possible) 

— High-fidelity templates, fixtures, etc. , if required 

• Exercise all functional paths 

• Identify all systems and subsystems and treat individually and 
collectively 

— Identify complex interfaces and test realistically, e.g., composite 
data-check with RAU or high-fidelity simulator, etc. 

• Exercise all mechanical devices possible-in 1-g environment 
— Provide 1-g adaptors and supports for selected payloads 

• End-to-end calibration verifications 

• Verify redundancy elements. 

• Verify data channelization 

• Include all loose and stowed flight hardware 

• Consider system proof tests 


Table D-8 

OWS PROBLEM DISTRIBUTION 

• OWS No. 1 Experiment Checkout Problem Summary: 

19% - Improper identification 
33% - Test procedure deficiencies 

28% - Minor discrepancies (loose, scratched, damaged) 
9% - Mechanical fit or interface 
11% - Hardware system malfunction 
100 % 
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